A self-hosted Uptime Robot alternative

Your site went down at 03:14. You have the alert. Now you want the logs from 03:14.

That is the gap self-hosted uptime monitoring closes, and it is the only reason to consider running your own instead of using a hosted checker. So let us be straight about the trade first, because it is a serious one.

The trade, stated plainly

Uptime Robot checks from outside your infrastructure, from several places in the world. Central Logging checks from your own server, from one place.

That difference has three consequences, and none of them are small.

1. If your server dies, so does your monitoring. A self-hosted checker cannot tell you it is down. You need something external watching the watcher.
2. One vantage point cannot tell “the site is down” from “my server cannot reach it”. A route problem between your log server and your target looks identical to an outage.
3. No public status page. Uptime Robot will publish a status page your customers can read. There is nothing like that here.

If external verification is the point of the exercise, use Uptime Robot. Their free tier covers a lot of sites, and a monitor that shares a failure domain with the thing it monitors is not a real monitor.

Read on if you want checks and history on your own disk, next to your logs, with no per-monitor pricing.

Side by side

What a check records

Add a monitor with a name and a URL, and pick a check frequency of one, two, five or ten minutes. The scheduler wakes every minute and runs whichever monitors are due. Each check stores:

• Response time, shown in the monitor’s history.
• HTTP status code.
• Resolved remote IP — useful when DNS changes under you.
• Response headers.
• TLS issuer and expiry for HTTPS URLs.
• Whether your keyword was present.
• Any connection error.

Details in website monitoring.

What actually fires an alert

Three things, and it is worth knowing exactly which three.

Connection errors. The request failed to complete — DNS failure, refused connection, timeout, TLS handshake failure. You get an alert, and a recovery alert when it comes back.

Keyword state changes. You nominate a string and say whether its presence or its absence is the problem. The alert fires when that state flips.

TLS certificates expiring within seven days. Throttled to once a day so it nags without spamming. This one quietly earns its keep — expired certificates cause more outages than most people admit.

The gap: HTTP status codes do not alert

A server that answers with 500 Internal Server Error has not failed to connect. The check records the 500, and no alert fires.

That is a real limitation compared to Uptime Robot, and it is fixable in about thirty seconds with a keyword check.

Pick a string that appears on a healthy page and nowhere on an error page — a nav item, a footer, an element only rendered when the database is reachable:

URL:        https://app.example.com/
Keyword:    Sign in
Alert When: not_exists

Now a 500, a blank white page, a maintenance page and a hijacked DNS record all trip the same alarm, because none of them contain “Sign in”. This is a better health check than a status code anyway — it tests that the page rendered, not just that something answered.

Better still, point the monitor at a health endpoint that only returns its magic string when its dependencies are up. Then one keyword check covers your database, your queue and your third-party API.

The part Uptime Robot cannot do

The alert says the site was unreachable at 03:14. In Central Logging, so are the logs.

Same server, same UI, same clock. Search the log source for that window:

SELECT timestamp, msg
FROM logs
WHERE timestamp BETWEEN strftime('%s', '2026-08-07 03:10:00')
                    AND strftime('%s', '2026-08-07 03:20:00')
ORDER BY timestamp;

Or set an alert rule that watches for the error itself and tells you before the uptime check does. A rule that fires on connection-pool exhaustion catches the outage while it is still building. Rules are evaluated every five minutes.

One caveat on that query: timestamp is when the server received the line, not when your application emitted it. They are close in normal operation and can drift apart when a host has been offline and its agent catches up. Where exact ordering matters, parse your own timestamp out of msg.

Things Uptime Robot does that this does not

• Checks from outside your network, from multiple regions, with agreement between them.
• Public status pages and maintenance windows.
• SMS, voice calls and email. Central Logging notifies over Slack, Telegram and Pushover only.
• Status-code and response-time thresholds as first-class alert conditions.
• Port and ping monitors. Central Logging checks HTTP and HTTPS URLs.
• A free tier, which for a handful of sites may be all you need.
• Someone else running it. Their uptime is their problem.

What you get in exchange

• Unlimited monitors with no plan boundary.
• Every check kept on your own disk, queryable, exportable, yours.
• TLS expiry alerting included rather than upsold.
• Cron and host monitoring in the same binary — cron jobs that stop checking in, hosts that go quiet.
• The logs, which is the whole point.
• One fixed cost.

Use both. Seriously.

This is not a page arguing you should cancel Uptime Robot.

The sensible arrangement for most small teams is one external checker watching your two or three most important URLs — including the Central Logging server itself — and Central Logging watching everything else from inside, where it can also see the logs.

The external checker answers “is it up from the internet”. The internal one answers “and what went wrong”. Different questions.

Who should choose which

Use Uptime Robot if you need external verification, a public status page, SMS or phone alerts, or on-call escalation.

Use Central Logging if you are already running it for logs, if you want more monitors than a plan allows, or if the first thing you do after an uptime alert is go looking for the logs.

Try it

The free download is the complete product, not a trial. Add one monitor with a keyword check and see how it reads.

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