Self-Hosted vs Paid Uptime Monitoring: Which to Use
Self-hosted uptime monitoring like Uptime Kuma vs paid services like Pingdom. Why you should run both, and which one actually tells you your site is down.
For uptime monitoring, the counterintuitive answer is that you should not fully self-host the thing that watches whether your servers are up. Self-hosted monitors like Uptime Kuma are excellent and I run one, but the monitor that checks your site must live somewhere your site does not. If your monitoring runs on the same infrastructure as your app, an outage that takes down the app can take down the alert that would have told you. The right setup combines a self-hosted monitor for depth with an external check for the one question that matters most: is the site reachable from the outside world?
The problem with monitoring your own box from your own box
Picture the failure. Your datacenter has a network problem. Your app goes dark. Your self-hosted monitor, running in the same datacenter, also goes dark, so it never fires the alert. You find out when a customer emails you an hour later. The monitor did its job right up until the moment you needed it, then failed at exactly the same time as the thing it was watching.
This is the core rule of uptime monitoring: the watcher must not share fate with the watched. A monitor inside your own infrastructure can tell you a lot about internal health, but it cannot reliably tell you the site is down, because the same failure can silence both. That one blind spot is why pure self-hosting is the wrong call here, even though I self-host almost everything else and cover the general case in self-hosting monitoring instead of paying per host.
What self-hosted monitoring is great for
Run Uptime Kuma or something like it, because it earns its place. Self-hosted monitoring gives you deep, cheap visibility into everything internal.
- Check every service, endpoint, and database across the fleet without per-check fees.
- Watch internal things an external service cannot see: queue depth, disk space, replication lag, certificate expiry.
- Keep the data on your own box, with no vendor pricing that scales with how many things you watch.
For a portfolio of twenty apps, the per-check pricing of commercial tools adds up fast, and a self-hosted monitor watching hundreds of internal signals costs the price of a small VPS. That is real leverage. The self-hosted monitor is your control panel for internal health, and it is where most of your monitoring depth should live.
What external monitoring is for
The external check answers one question: can a user out on the internet reach my site? Use a service whose whole job is to probe your site from outside your infrastructure. It runs from locations you do not control, so when your datacenter has a problem, the external probe still works and still alerts. Even a free tier of a hosted uptime service covers this.
Keep the external checks simple and focused on user-facing reachability. Is the homepage returning 200? Is the login endpoint responding? Is the API up? These are the signals that map to "customers are affected right now," and they must come from outside, because outside is where your customers are. This is the check that survives the outage that silences everything else.
How to combine them without alert chaos
Running two systems risks doubling your alerts, so divide the labor cleanly.
- External service: a small number of critical, user-facing checks. These page you loudly, because they mean customers are affected.
- Self-hosted monitor: the deep internal checks. These feed dashboards and lower-urgency alerts about things trending toward trouble.
The external system answers "are we down." The self-hosted system answers "why, and what is about to break." Keeping those roles separate is most of what stops alert fatigue, which is the real enemy of any monitoring setup. Too many alerts and you stop reading them, and then a real one slips past.
The cost math favors this split. The external tier you need is cheap or free because it is a handful of checks. The deep tier is self-hosted, so it does not bill you per signal. You get comprehensive coverage without either the blind spot of pure self-hosting or the runaway bill of pure commercial monitoring.
I run a self-hosted monitor across my whole portfolio on HostSSH for internal depth, backed by a small external service for the one question that matters when a datacenter goes dark. Self-host the depth, outsource the outside view. The watcher and the watched must not fail together, and that single rule decides the architecture.