Observability Cost

Observability Cost owns what your monitoring stack costs and what that money buys. It attributes vendor spend to the teams and services generating it, finds the volume nobody queries, and proposes the retention, sampling, and filter changes that remove the waste. This page covers the outcome the module owns, the two workflows inside it, and what it needs connected.

​

What this module owns

Observability spend grows by default. Every new service ships metrics, every incident adds a dashboard, and one high-cardinality label added in a hurry can move a bill by a noticeable percentage. Nothing removes any of it, because deleting telemetry feels like deleting the thing that will explain the next outage. That fear is reasonable, which is why this module leads with attribution rather than deletion: knowing which tool, which service, and which team a line of spend belongs to turns a blunt budget conversation into a specific one. Then waste detection does the unglamorous part — finding the metric with cardinality nobody queries, the dashboard nobody opens, the log source producing volume nobody reads — and every proposal states what you lose by accepting it. Good looks like observability spend that maps to owners, a ranked list of what to cut, and no investigation ever failing because this module removed something.

​

The workflows inside it

This module contains 2 workflows.

​

Observability cost allocation

​

Observability spend reduction

​

What it needs connected

​

Enabling it

​

What you see when it runs

The module lists waste findings — the metric, dashboard, or log source, what it costs, and what the proposal would save — plus the showback records the allocation workflow produces. Each finding carries the run behind it, so a recommendation to drop something is reviewable rather than a suggestion out of nowhere.

​

Next steps