Observability cost review: what I check in 5 days

The Observability Cost Review is a fixed-price piece of work: five working days, async, €2,500. The first three clients who agree to an anonymised case study pay €1,500. At the end you have four things in writing: a breakdown of what your current metrics, logs and traces spend buys, a list of cardinality and retention quick wins, a migration plan to open source where it pays off, and a savings estimate in euros.

This article explains what the review checks, in what order, and how the guarantee works. It is written for two readers: the person deciding whether the review is worth the fee, and the engineer who will work with me on it.

First: a 30-minute call to agree the scope

The review starts with a 30-minute call to agree the scope and what I need to see, usually usage and billing data and a rough picture of the platform. The rest of the review runs async.

Step 1: what the spend buys

An invoice says how much you pay per product. It does not say what you get for it. The first step turns the bill into a table that answers that: each line of spend, the unit it is billed on, what drives it, and what it supports.

For a Datadog customer, the lines are usually hosts, custom metrics, log ingestion, log indexing and APM, the four meters I describe in why your Datadog bill grows faster than your product. For each one I work out the unit cost (per host, per 100 custom metrics, per million indexed events) and map usage to the services, teams and environments that produce it.

Then the question that matters: which of it is used? A metric that feeds an alert or a dashboard someone opens during incidents is doing its job. A metric family with 50,000 series that no dashboard, alert or saved query reads is pure cost. The table makes it obvious when a few metric names, log sources or tags account for most of the bill.

A row in that table reads like this, taken from the worked example in the Datadog article: log indexing, $1,550 a month at list price, for about 912 million events kept searchable for 15 days. The follow-up questions are which of those events anyone searched in the last quarter, which ones fed a monitor, and which could have been counted as a metric or dropped before they were sent.

Step 2: metrics, cardinality and retention

The second step goes through metrics with the same steps as my cardinality and retention checklist for Prometheus-compatible stacks, adapted to wherever your metrics live:

Top series by metric name and by tag. Which tags multiply series counts (pod, container_id, customer or user IDs, raw URL paths), and whether anyone groups by them.
Unused metrics. Names that no dashboard or alert reads, checked against the list from step 1.
Histograms and distributions. Bucket counts and percentiles nobody looks at. In Datadog, enabling percentiles doubles a distribution’s custom metric count.
Retention. How far back people actually query, compared with what is stored.
Scrape intervals and churn if you run Prometheus-compatible storage, since those decide disk and memory.

Each finding goes on a list with an estimated saving and a risk note. “Remove the pod_name tag from these four metrics” is low risk if no dashboard groups by pod. “Shorten metrics retention to 90 days” needs someone to confirm nobody runs year-on-year capacity reports.

Step 3: logs and traces

Logs were about a third of the bill in the worked example of the Datadog article, and they are easy to cut once you know where the volume comes from. I look at:

Volume by source and by level. Debug logging left on, health checks, access logs and retry loops usually stand out.
What is indexed compared with what is searched. In Datadog, everything sent is billed for ingestion, and indexing costs much more per GB than ingestion does. An exclusion filter saves only the indexing part, so dropping at the agent or collector usually saves more.
Retention per index, set against how far back your incidents and audits actually look.
Tracing coverage and sampling. Which services are traced, whether anyone uses those traces, and whether tail sampling (keep every error and slow trace, sample the rest) would keep the useful ones at a fraction of the volume.

Step 4: a migration plan, where it pays off

With the quick wins counted, I compare two futures: staying on the current vendor with the quick wins applied, and moving some or all signals to a self-hosted stack such as VictoriaMetrics, VictoriaLogs, OpenTelemetry and Grafana. The self-hosted side includes machines, storage and the engineering time to run it, the same way my observability cost calculator does.

Sometimes the answer is to stay. At small scale the self-hosted option can cost as much as the vendor once engineering time is counted. With 50 hosts, 50,000 custom series, 50 GB of logs a day and 20 APM hosts, the calculator’s monthly saving runs from below zero to about €5,600. A range that crosses zero means the decision depends on details the calculator cannot see, and that is what the review is for. When the saving does not justify the move, the plan says so, and the quick wins become the main result.

When a migration does pay off, the plan goes signal by signal, usually metrics first, because they are the easiest to compare between two systems.

Running old and new side by side

The usual worry about migrating observability is losing visibility during an incident halfway through. The plan avoids that by never switching off the old system until the new one has proven itself:

Send to both. Agents or an OpenTelemetry collector export the same data to the current vendor and to the new store. Nothing is turned off.
Rebuild what matters first. The dashboards and alerts from the step 1 list that people actually use, not every dashboard ever created.
Compare. Run both through real traffic, a release and ideally an incident, and check that alerts fire on both sides and that the numbers agree.
Cut over one signal at a time. When metrics are trusted on the new stack, stop sending them to the vendor and lower the plan. Then logs, then traces.
Keep the old data readable until its retention runs out, so history is not lost on the day of the switch.

The overlap costs money, because you pay for both while it lasts. The plan states how long it lasts and what it costs, and the savings estimate counts it.

Step 5: the savings estimate

The last step puts numbers on everything. The estimate is in euros per year, as a low and a high figure, with every assumption written next to it: list or contract prices, exchange rate, volumes, and the engineering hours for each change. Quick wins and migration are kept separate, because one is a few days of work and the other a project, and you may want only the first.

Within the five working days you get, in writing, the spend breakdown, the quick-win list ranked by saving and risk, the migration plan where it pays off, and the savings estimate, written so your team can act on it. If you want help with the implementation, that is scoped separately, at a day rate or a fixed price.

The guarantee

If the annual savings I identify are less than twice the fee you paid, I refund the difference, up to the full fee. On the €2,500 fee, savings of €4,000 a year mean a €1,000 refund; at the €1,500 launch price the threshold is €3,000.

The guarantee exists because the review should pay for itself in money you can see on an invoice.

Who it is for

The review fits European software companies with roughly 10 to 150 engineers, running production on Kubernetes in a public cloud, with a Datadog or New Relic bill growing faster than the product, or a self-hosted Prometheus-compatible stack that keeps needing bigger machines. It does not fit pre-product startups, or teams looking for 24/7 on-call cover.

Why I do it this way

I start from the bill because that is the number the person who signs it cares about. The habit comes from platform work: in my current role, the sole SRE for three multi-tenant SaaS products at a European cloud provider, I saved €96,400 a year by removing a platform component nobody needed. On RESTIA, the restaurant software platform I designed and run, metrics, logs and traces are self-hosted. Thirteen months of about 68,000 active series are sized at about 22 GB (projected from a measured 0.26 bytes per sample), and the metrics database runs within 2 GiB of RAM and 1 CPU. At Datadog list prices, the same metrics would cost an estimated €670 to €3,100 a month (metrics only, computed with the calculator’s prices).

If you want a first number before talking to anyone, try the observability cost calculator. When you want the full picture for your setup, the Observability Cost Review starts with a 30-minute call.