Datadog Log Management: Loved Until the Invoice Arrives

Do the math before you feel the pain. A modest five-service SaaS emitting a few hundred log lines per second produces on the order of a billion log events a month. With log management in Datadog, you don’t pay one price for those logs — you pay separately to ingest them and to index them, and the index side is priced per million events. Index everything at a billion events and you’re into four figures a month for logs alone, at a company whose entire infrastructure bill might be $800. That’s not a pricing bug. It’s the design, and it’s the single most misunderstood thing about the platform.

I ran a two-person backend on Datadog for about a year. The product was the best part of my tooling and the worst part of my budget, and both of those things were my fault for not understanding the model earlier.

How log management in Datadog is actually priced

Per their public pricing as of mid-2026, Datadog splits logs into two meters:

Ingest is priced per GB and is genuinely cheap. This covers receiving your logs, parsing them through pipelines, and archiving them to your own S3/GCS bucket if you configure that. Everything you send passes through here.

Indexing is priced per million events, tiered by how many days of retention you want, and this is the meter that produces invoice screenshots on social media. An indexed log is searchable, facetable, alertable — all the things you actually opened Datadog to do.

The mental model that finally made it click for me: ingest is the postal service, indexing is the filing cabinet with a librarian. Datadog will happily accept and archive every letter you send for pennies. The moment you want a letter findable, you pay the librarian, per letter, per day of shelf life.

The trap for small teams is that the default posture is “index everything,” because that’s what happens if you install the agent and change nothing. Every debug line, every health-check request log, every load balancer heartbeat gets the full librarian treatment. Nobody will ever search 95% of it.

Exclusion filters: the only setting that matters in month one

Datadog lets you define exclusion filters on your indexes: rules that drop matching logs from indexing while still counting them as ingested (and still archivable). This is the entire cost-control game, and it’s genuinely well designed — you keep everything, you just stop paying librarian rates for noise.

What I’d exclude first, in order of typical volume:

1. Health checks and probes. /healthz request logs from your load balancer and orchestrator are the classic offender — steady, enormous, and containing zero information after the first one.
2. Debug and info logs from stable services. Keep warnings and errors indexed. If a service has been quiet for six months, its info logs are archive material.
3. Sampled success paths. Datadog exclusion filters support percentage-based sampling, so you can index 5% of 200-OK request logs — enough to see the shape of normal traffic — and drop the rest.

One evening of writing exclusion filters routinely cuts an indexing bill by well over half. Mine dropped by roughly three-quarters, which was simultaneously a relief and an indictment of what I’d been paying for.

The uncomfortable flip side: every exclusion filter is a bet that you won’t need those logs in a search. Sometimes you lose the bet.

Rehydration: paying to un-archive your own logs

When you lose the bet, Datadog’s answer is rehydration: you select a time range and a query, and it reads matching logs back out of your archive bucket and indexes them temporarily so you can search them. It works. It’s also billed (per their public docs, priced per volume scanned or rehydrated), and it’s slow relative to a live search — think “come back after coffee,” not “instant.”

In practice, rehydration is fine for the incident post-mortem on Thursday about the weirdness from last Friday. It is miserable for interactive debugging, where each “hmm, let me widen the query” costs another round trip. The workflow pushes you toward a two-tier discipline: errors and warnings always indexed and instantly searchable; everything else archived, retrievable with ceremony.

That discipline is honestly not a bad way to live. But notice what happened: you’re now doing active log-budget management — filters, sampling rates, rehydration decisions — as a recurring engineering chore. That overhead is invisible on the invoice and very visible in your week. Most of it is the same hygiene you should do anywhere (drop noise, structure your logs, sample the boring stuff — the same practices that keep log management sane for a small team on any backend), but Datadog raises the stakes: sloppy hygiene elsewhere costs disk, sloppy hygiene here costs real money every month.

When a small team should just not be on Datadog

Datadog is excellent. That needs saying plainly: the query experience is fast, pipelines and facets are polished, correlation between logs, APM traces, and infrastructure metrics is the best in the business, and if someone else is paying, choose it without guilt.

But “is it good” was never the question. The question is whether its pricing model fits your scale, and per-million-events pricing punishes exactly the thing small SaaS backends produce: high-volume, low-value logs from a small number of hosts. The people who thrive on Datadog either have Datadog-sized budgets or treat log-budget engineering as a real, staffed function. A five-person team has neither.

My heuristic, for whatever it’s worth:

• Under ~$100/month of honest projected usage: fine, stay, but set up exclusion filters on day one, not month three.
• Trending past a few hundred dollars a month for logs on a team under ten engineers: you’re subsidizing capabilities built for companies with a thousand services. A self-hosted or flat-priced stack — ClickHouse-backed tools, Loki + Grafana, or an all-in-one platform with OpenTelemetry ingest — covers the debugging workflow of a small team for the cost of one VPS.
• The moment you catch yourself not logging something because of the bill: leave. That’s the tail wagging the dog, and I say this as someone who once shipped a service with error-level-only logging to protect a budget, then spent a weekend debugging it blind. The tool is supposed to reduce the cost of incidents, not add a line item to them.

None of this is a moral judgment on Datadog. Usage-based pricing on logs is a defensible model that simply has a floor below which it stops making sense. Know whether you’re below it before the invoice tells you.