Here is a mistake almost everyone makes once. You install an uptime monitor on the same server as your app, point it at your site, and feel responsible. Then the server dies at 3am. The app goes down, and so does the thing that was supposed to tell you the app went down. You find out at 9am from a customer.
An uptime monitor is only as useful as its independence from the thing it watches. That single idea decides almost every choice in this space: which tool, where it runs, and what it costs. This guide walks through the placement question first, then the tools that fit each answer.
The one rule: a monitor must fail separately
An uptime check is a request from the outside world to your service on a timer. If the request fails, you get an alert. For that to work, three things have to stay up when your app does not:
- The machine running the checks. If it shares hardware, a power supply or a hypervisor with your app, one failure takes out both.
- The network path to the alert channel. A monitor on a box with a dead uplink cannot reach Slack, email or a phone.
- The monitor’s own storage. If the disk filled up and killed your app, it probably killed your monitor’s database too.
So the practical rule is simple: run the monitor somewhere that shares nothing with production except the internet. A different server, ideally a different provider or at least a different region. Everything below is a way of satisfying that rule at different price points.
Option 1: a hosted SaaS monitor (independent by design, priced per check)
The easiest way to get independence is to pay someone else to run the monitor. UptimeRobot, Better Stack and Pingdom all check your endpoints from their own infrastructure, so a failure on your side can never silence them.
The catch is the pricing model. Hosted monitors bill per monitor and per check interval. The free tiers are real but narrow: UptimeRobot’s free plan covers 50 monitors at a 5-minute interval, and Better Stack’s free tier is 10 monitors. Once you want 1-minute checks, a branded status page or SMS alerts, you are into a paid plan, and Pingdom’s synthetic monitoring starts at about $16.50-18 a month for 10 checks. Prices move, so check the vendor pages before you commit.
Five minutes sounds fine until you realise it means an outage can run for almost five minutes before the first failed check even happens, plus whatever retry delay you configured before the alert fires.
Pick this if: you have a handful of endpoints, you are fine with 5-minute resolution, or you want on-call rotations and escalation built in.
Option 2: a self-hosted monitor on its own small server
The other route to independence is to run an open-source monitor yourself, on a machine that does nothing else. This is where most self-hosters end up, because the economics flip: the software is free, the checks are unlimited, and the only cost is one small server.
The tools worth knowing:
| Tool | Best at | Min check interval | Status page | Config style |
|---|---|---|---|---|
| Uptime Kuma | General HTTP/TCP/DNS/ping monitoring with a friendly UI | 20 seconds | Built in | Web UI |
| Gatus | Health checks as code, reviewed in Git | Configurable | Built in | One YAML file |
| Healthchecks | Cron jobs and backups (dead-man’s switch) | Per job schedule | Basic | Web UI |
Uptime Kuma is the default for a reason. It watches HTTP, TCP, DNS, ping, Docker, gRPC and more, ships a status page, and talks to 90+ notification services. It checks as often as every 20 seconds, which is the difference between “down for 20 seconds” and “down for five minutes” in your alert history.
Gatus suits teams who want every health check reviewed in a pull request. The whole config is one YAML file, and the status page renders from it.
Healthchecks solves a different problem that HTTP monitors cannot see: jobs that silently stop running. Your nightly backup pings Healthchecks when it finishes. If the ping does not arrive, you get the alert. Pair it with one of the other two.
If you are choosing between these and hosted tools in more depth, this comparison of the best uptime monitoring tools tests seven of them on interval, alerting, status pages and real cost.
The part that used to be annoying
The classic objection to self-hosting a monitor is the setup, not the software. To run Uptime Kuma on its own box you have to provision a server, install the runtime, configure nginx as a reverse proxy, set up SSL, open the firewall, keep the process alive with a process manager, and point a domain at it with the DNS records to match. That is an afternoon for a tool whose whole job is to send an HTTP request every 20 seconds.
That friction is why managed app hosts exist. InstaPods, for example, runs Uptime Kuma as a one-click app for a flat $3/mo, with the domain, SSL and process management already handled. It is still a real Linux server you can SSH into, so you are not locked into anything. The point for this article is placement: it lives on infrastructure that has nothing to do with wherever your production app runs, which is exactly what the one rule asks for.
Pick this if: you watch more than a handful of endpoints, you want sub-minute checks, or you would rather pay a flat monthly price than per monitor.
Option 3: both (the setup most serious teams run)
Once a product has paying customers, the answer is usually “both”. A self-hosted Uptime Kuma does the detailed, fast, unlimited checking and hosts the public status page. A free hosted monitor (UptimeRobot’s free tier is plenty) watches the Uptime Kuma instance itself, plus your most important endpoint.
Now you have a monitor for your monitor, on a completely separate provider, for zero extra dollars. If your self-hosted box ever dies, the hosted check tells you. It is the cheapest insurance in this whole guide.
Uptime monitoring is not server monitoring
One last thing that trips people up: an uptime monitor answers “can the outside world reach my service right now?” It does not tell you that your disk is 94% full or that memory has been climbing for three days. Those are resource metrics, and they come from an agent running on the server itself.
That is where tools like Beszel, Netdata and Prometheus come in. They live on (or next to) the machine they watch, which is fine, because their job is trend-spotting before an outage, not alerting during one. If you want the resource side as well, here is a rundown of the server monitoring tools worth running in 2026.
The healthy setup has both layers: a resource agent that warns you a week early, and an independent uptime check that catches whatever slips through.
The short version
- Never run your only uptime monitor on the server it watches. If they can fail together, they will.
- Under 10 endpoints and 5-minute checks are fine: use a free hosted tier.
- More endpoints or faster checks: self-host Uptime Kuma on its own small server, for a flat monthly cost instead of per-monitor billing.
- Cron jobs and backups: add Healthchecks, because HTTP monitors cannot see a job that never ran.
- Production with customers: run both, and point the free hosted monitor at your self-hosted one.
Twenty minutes of setup now is the difference between hearing about an outage from your phone and hearing about it from a customer.