Datadog bills rarely spike. They creep. A few more hosts this quarter, a little more log ingest, one synthetic check quietly dropped to run every minute, and an invoice or two later it's a line item finance wants a meeting about.
The reflex is to rip Datadog out. That's almost always the wrong move: it throws away the part you were right to pay for, and it doesn't touch the reason the number grew in the first place.
There's a cheaper answer most teams walk straight past: keep Datadog for what only Datadog does, and stop routing commodity monitoring through the most expensive tool you own.
Synthetic runs per month, per endpoint, from one check firing every minute: that's 60 × 24 × 30, and every run is metered. Now multiply by your endpoints.
What Datadog earns its price on
Datadog is genuinely worth the money on deep observability, the things that are hard to build and harder to replace:
If you lean on these, keep them. This isn't leave-Datadog advice, it's use-Datadog-only-where-it-wins advice.
What you're almost certainly overpaying for
The costly part of most bills isn't the tracing. It's the commodity monitoring stacked on top, billed by units that scale fast:
None of that is deep observability. It's is it up, is it fast, is it reachable, and a focused monitor does exactly that for a flat monthly price instead of a spinning per-unit meter.
Where the money actually is
illustrative, run your own numbersRun two tools, on purpose
The split stack isn't a downgrade. It's putting each job on the tool priced for it, and letting the expensive meters stop spinning on commodity checks.
What moves easily, and what stays
Most of the commodity layer moves over in an afternoon. The deep observability stays exactly where it is.
One thing worth noticing: the public status page has no Datadog equivalent at all. And if you don't lean on traces, logs and RUM much, that's a signal too: you might not need Datadog in the first place, in which case the Datadog alternatives are worth a look.
Replacing the commodity layer, capability by capability
"Move the monitoring" is easy to say and vague enough to be useless. Here is the actual mapping: what Datadog meters, what replaces it, and where the replacement stops. If a row below matters to you and the replacement does not cover it, that is a reason to stay.
Uptime and keyword checks
Datadog bills these as Synthetic tests, metered per test run, which is why teams quietly cap their check frequency to keep the bill down. That is exactly backwards: the cheapest monitor is the one that catches an outage before a customer does.
The replacement is an HTTP check with an interval you choose, down to 10 seconds, plus keyword checks that assert what must and must not appear in the response body. A page that returns 200 while rendering a stack trace is still broken, and a status-code-only check will happily call it healthy. Ping and port checks cover the layers underneath.
API response checking
An API that is up is not the same as an API that is correct. The check that earns its keep asserts on the payload, not just the status line: the shape of the response, a specific field, and the latency it came back in. That catches the deploy that starts returning an empty array with a cheerful 200.
You also want the latency chain broken out, DNS, connect, TLS and time-to-first-byte, because "the API is slow" and "TLS negotiation is slow" have completely different fixes and a single response-time number cannot tell them apart.
Database connectivity and query health
This is where port checks quietly lie to you. A Postgres primary with a full disk still accepts connections on 5432. TCP is fine. The port is open. Every naive check is green, and writes have been failing for twenty minutes.
The replacement connects properly to PostgreSQL, MySQL or Redis and runs a real query, so what you are measuring is whether the database can actually serve, and how long it took. Credentials are held in a secrets store rather than sitting in a monitor config.
SQL value assertions
The capability most teams do not realise they want until they have it: assert on what a query returns, not just that it returned. Queue depth above a threshold. Rows in a dead-letter table. Payments stuck in pending for longer than they should be. Failed jobs climbing.
These are business-level failures that no infrastructure metric surfaces. CPU is normal, memory is normal, every host is green, and orders have not been dispatched since 3am. Doing this in Datadog means either a custom metric per value you care about, each one metered, or a scheduled job you build and maintain yourself.
Server and host metrics
CPU, memory, disk, load average and network throughput, collected by a single static Go binary that runs as a systemd service and posts on an interval. No inbound ports, no agent fleet to orchestrate.
Datadog prices infrastructure per host per month, so this line scales with your fleet whether or not you look at the dashboards. It is the single most common reason a bill grows without anyone deciding it should.
Custom application metrics
Push any number you can produce, signups this hour, cache hit ratio, items awaiting review, and define what healthy looks like for it. This is the escape hatch that stops monitoring being limited to what your infrastructure happens to expose.
Datadog's custom metrics are billed per metric name and tag combination, which is the line item that surprises people most: a well-intentioned tag on a high-cardinality field can multiply your custom-metric count overnight. A flat tier removes the incentive to under-instrument.
What none of this replaces
Worth repeating plainly, because a comparison that only lists wins is not useful to anyone making a real decision. There is no APM, no distributed tracing, no log analytics and no real-user monitoring here. If you need to follow one request across nine services, or query a month of logs to reconstruct an incident, that is Datadog's job and it does it well. The argument in this post is not that you should leave. It is that the uptime, database, server and custom-metric layer does not need to be billed at observability rates.
Work out your own number
The savings depend entirely on your setup, so don't take our word for it. Drop your real monitor counts into the cost comparison, or read the full NoDisrupt vs Datadog breakdown. For most teams the commodity layer is where the money is, and it's the easiest part to move.