A self-hosted Better Stack alternative

Better Stack had the right idea. Logs and uptime belong in the same tool.

Anyone who has correlated an outage across two vendors’ timestamps agrees. Better Stack put log management and uptime monitoring behind one login and it is genuinely nicer than running two products.

Central Logging makes the same bet about consolidation and lands somewhere different: not a hosted platform, a single binary on your own server.

The same idea, two shapes

Cost is structural, not a number

Better Stack meters usage. Ingested volume, retention, monitor count. That model is fair and it is also the reason people go looking: the bill tracks how much you log, and how much you log tends to go up.

The specific consequence is behavioural. Under per-GB pricing, teams start trimming what they log. Debug logging gets turned off. Retention gets cut to the shortest tolerable window. Somebody suggests sampling. Every one of those decisions makes the tool less useful at the exact moment you need it most.

Central Logging is $187 once. The cost of logging more is disk, which you can buy in advance and which is cheap. Nobody has to argue about whether a debug line is worth the money.

The honest counterweight: your ceiling is a single server. The economics stop being an advantage at the point where one machine cannot hold the volume, which for this design is roughly 10GB/day.

What Better Stack does that this does not

This is the important section, because Better Stack does several things Central Logging has no answer for.

• On-call and incident management. Rotations, escalation policies, acknowledgement, phone calls at 3am. Central Logging sends a Slack message. That is the whole incident response feature.
• Public status pages. Hosted, branded, with maintenance windows.
• Alerting that reaches a phone. No SMS, no voice, no email channel here.
• External vantage points. Their checks run from their regions. Yours run from your server, which means a self-hosted uptime check cannot tell you your own server is down. Keep one external checker pointed at it.
• Team accounts, roles and SSO. Central Logging has one admin login and no per-user permissions.
• Scale and retention without you thinking about disks.
• A support contract, and someone whose job is keeping it running.

If you need on-call escalation or a status page your customers read, this comparison is already over. Those are not small features and nothing in a single binary replaces them.

What Central Logging adds

Your logs stay on your disk. They are SQLite files in a directory. That answers the data-residency question in one sentence, and it makes backups a file copy. Teams with contractual limits on where customer data lives usually cannot use a hosted log product at all — see on-premise logging.

No metering, so no self-censorship. Log what is useful.

More in the same binary than the bundle covers. Host monitoring alerts when a server stops checking in, and Prometheus scraping charts your application metrics without a Prometheus and Grafana install.

SQL you can take with you. Better Stack’s log querying is SQL over ClickHouse, so the query experience is comparable — this is not a page claiming SQL as a differentiator. The difference is what happens when you leave. Your data is a SQLite file any client can open. There is no export step.

SELECT
    json_extract(msg, '$.service') AS service,
    COUNT(*)                       AS errors
FROM logs
WHERE json_valid(msg)
  AND json_extract(msg, '$.level') = 'error'
  AND timestamp > strftime('%s', 'now', '-24 hours')
GROUP BY service
ORDER BY errors DESC;

One thing to install and update. No agents to keep on a version, no collector fleet. Ship logs over HTTP:

curl -X POST https://logs.example.com/api/v1/ingest_logs/YOUR-SOURCE-TOKEN \
    -d @mylogs.txt

Or install the CL Agent and it ships the journal for you.

Moving off a hosted bundle

Three pieces, and none of them require a flag day.

1. Logs. Point one service at the ingest endpoint and leave the rest where they are. Run both for a fortnight.
2. Uptime checks. Recreate them as website monitors. Use a keyword check rather than relying on status codes — Central Logging alerts on connection failures, keyword changes and TLS expiry, not on a 500 response. Details on the Uptime Robot comparison.
3. Cron checks. Change the ping URL. The shape is the same: one API key, a job name per job, ?state=complete. See cron monitoring and the Healthchecks.io comparison for how the missed-run detection differs.

Keep one external uptime check on the Central Logging server itself. A monitor that shares a server with the thing it monitors is not a monitor.

Who should choose which

Stay with Better Stack if you have an on-call rotation, if customers read your status page, if alerts have to reach a phone, or if nobody on the team wants to run a server.

Switch if your logs are not allowed to leave your infrastructure, if the usage bill has started shaping what you are willing to log, or if you want one binary instead of a subscription and are under about 10GB/day.

Try it

The free download is the complete product, not a trial. Run it alongside what you have and compare on a real incident, not a feature grid.

14-day refund if you buy and it does not fit. Deploy has the setup.