A cheaper self-hosted Datadog alternative for logging

Almost nobody shops for a Datadog alternative because Datadog broke. They shop because the invoice arrived.

Datadog is a good product. For a lot of small teams it is also the biggest line item in the infrastructure budget.

So this page asks one question. If you are a small team using Datadog mostly for logs, alerts, and uptime checks, can you cover that ground for far less?

Be honest about what you use

Open the bill first. Datadog is a suite — infrastructure monitoring, APM, log management, synthetics, RUM, security — and each part prices on its own dimension.

Central Logging does not replace Datadog. It replaces one slice:

Do you trace requests through a service mesh to debug it? Keep Datadog. Did you turn on APM two years ago and look at it twice since? Different calculation.

Why Datadog logging bills grow the way they do

Datadog prices log management on more than one axis. Ingestion bills separately from indexing, and retention tiers cost more the longer you keep data. The design is defensible. The consequence is well known: cost scales with how much you log and how long you keep it, and both grow on their own.

Then comes the exclusion filter conversation. The team stops indexing debug logs. Then stops indexing a noisy service. Then shortens retention. Every step is reasonable on its own.

Now an incident hits, and the logs you need are the ones you filtered out to save money.

Central Logging costs $187 once. Volume costs disk. Retention costs disk. Disk is cheap, so the pressure to log less goes away.

The architecture trade

You trade breadth and scale for cost and control. Good trade for a bootstrapped team running ten servers. Bad trade for a platform team running a thousand.

What querying looks like

Central Logging stores logs in SQLite, so queries are plain SQL with json_extract for structured fields:

SELECT
    json_extract(msg, '$.status')      AS status,
    json_extract(msg, '$.request_uri') AS uri,
    COUNT(*)                           AS hits
FROM logs
WHERE json_valid(msg)
  AND json_extract(msg, '$.status') >= 500
GROUP BY status, uri
ORDER BY hits DESC
LIMIT 25;

No proprietary query language to learn. No per-query cost to think about. Know SQL and you already know the tool. Full-text search handles the cases where SQL is overkill:

+error -healthcheck "connection refused"

Alerting

Alert rules are SQL or full-text queries. Central Logging runs them every five minutes and delivers hits to Slack or Telegram. Set a max frequency and a long outage sends one alert instead of a pager storm.

SELECT COUNT(*) AS errors
FROM logs
WHERE json_valid(msg)
  AND json_extract(msg, '$.level') = 'ERROR'
HAVING errors > 50;

Datadog’s monitor system is more capable than this. It has anomaly detection, forecasting, and composite monitors. Central Logging has none of those. It handles threshold and absence alerting on logs, which covers most of what teams write.

Migrating the log pipeline

Datadog log shipping falls into three patterns. Each has a direct equivalent.

Datadog Agent collecting system logs → the CL Agent ships journald entries:

sudo ./clagent -install
sudo systemctl enable --now clagent

Container logs via the Agent → switch Docker to the journald driver and let the agent forward them. See the Docker guide.

Application logs via a Datadog library appender → POST to the ingest API instead. Most logging libraries need a formatter and one handler change. The Python guide shows a complete example.

Run both pipelines in parallel until you trust the new one. Then turn off Datadog log ingestion. Keep other Datadog products and you shrink the bill rather than end it.

When to stay on Datadog

• You use APM and distributed tracing for real work.
• You log more than about 10GB per day.
• You have a platform team, and their time is worth more than the savings.
• Customers ask you for SOC 2 reports and vendor SLAs.
• You require multi-region, high-availability observability.
• Your company would rather pay an operating expense than run infrastructure.

When to switch

• Logs, alerts, and uptime are most of what you use.
• The bill grew faster than your traffic.
• You built exclusion filters to save money.
• You already run servers, so one more service is nothing.
• You want log data to stay on your own infrastructure.
• You are a small team with no platform engineer.

Try it against real data

The free download is the full product with no time limit.

Point a day of real production logs at it. Run the queries you reach for during an incident. That comparison beats any feature table, including this one.

Buy it and find it wrong for you, and there is a 14-day refund. See Deploy.