Uptime Monitoring for Solo Founders: UptimeRobot vs Uptime Kuma vs Better Stack (2026)
We ran our self-hosted uptime monitor on the same VPS as the sites it was watching. When the server died, so did the alerting. Here is what we learned, and what the three real options actually cost.
We evaluate every tool based on published features, real-world usage, community feedback, and independent testing where possible. Affiliate commissions never influence our rankings. How we research · Editorial policy
The short version
Use UptimeRobot on the free tier if you want this solved in four minutes and never thought about again. Use Uptime Kuma if you already run a VPS, want unlimited monitors, and are willing to accept that you now own another service. Use Better Stack if you want uptime, logs, and a status page from one dashboard and can justify the paid tier.
The one rule that matters more than the tool choice: do not run your monitor on the machine it monitors. We did. It cost us the only alert that would have mattered.
This is the companion piece to our error monitoring comparison. Uptime monitoring answers "is the server responding". Error monitoring answers "is the code working". They are different jobs and you eventually want both.
What uptime monitoring actually catches
An uptime monitor makes an HTTP request to a URL on a schedule. If it gets a response in time, it stays quiet. If it does not, it tells you. That is the entire product. Everything else the vendors sell you is packaging around that loop.
The failures it catches well are the total ones. The VPS ran out of memory and the kernel started killing processes. Nginx is running but the app behind it is not, so every request returns 502. A certificate expired overnight and every browser now refuses the connection. The DNS record was edited and never propagated. Docker restarted the host and three containers came back on different ports than the reverse proxy expected.
That last one is not hypothetical. It is the specific failure mode that made us pin every container port in our compose files, and it is the reason the deploy standard across our projects now forbids bare port numbers. A monitor is how you find out it happened at 6am rather than at lunchtime.
The failures it catches badly are the partial ones, and that gap is bigger than most setup guides admit. We cover it below, because assuming a green dashboard means a working site is how you end up shipping broken pages for a fortnight.
The mistake we made: monitoring the box from inside the box
We self-host a lot. Analytics runs on our own VPS rather than a hosted plan, and that decision has paid off. So when it came to uptime monitoring, the instinct was the same: run Uptime Kuma in Docker, on the VPS, alongside everything else. Free, unlimited monitors, nice dashboard, full control. It felt consistent with how we run everything else.
It worked fine for weeks. Then the actual incident arrived. One of our containers started consuming memory badly, the VPS ran out, and the kernel began killing whatever it could reach. Several sites went down. That is precisely the moment an uptime monitor exists for.
No alert arrived. Uptime Kuma was a container on the same host. It went down with everything else. A monitor that shares a failure domain with the thing it monitors is not a monitor, it is a dashboard that happens to be green until it is not there at all.
We found out the ordinary way, which is to say by looking. The gap between the sites going down and us noticing was several hours, and the only reason it was not worse is that this is a portfolio of small products rather than something with a support queue.
The lesson is not "self-hosting is bad". We still self-host plenty and still recommend it where it fits. The lesson is narrower and more useful: uptime monitoring is the one service that must live outside your infrastructure, because its entire job is to survive your infrastructure failing. Self-host the things whose failure you want to be told about. Do not self-host the thing doing the telling.
UptimeRobot: the boring default
UptimeRobot has been doing this since 2010 and the product reflects it. You paste a URL, choose an interval, add an email address, and you are finished. There is no onboarding flow to survive and nothing to configure that you will regret later.
The free tier has historically covered 50 monitors at five-minute intervals, which for a solo founder with a portfolio of products is more headroom than you are likely to need. Alerts go to email and integrations. Paid tiers buy you shorter intervals, SMS and phone alerts, and longer retention. Check the current pricing page before you plan around specific numbers, because the free tier terms have been revised more than once over the years.
The honest weakness is that five-minute checks mean a short outage can pass entirely unnoticed. If your app goes down for three minutes and comes back, you may never hear about it. For most solo products that is genuinely fine. If you are running something where a three-minute outage costs money, you are past the point where the free tier is the right answer.
The reason we recommend this as the default is not that it is the best product. It is that it is external, it is free, and the setup cost is low enough that there is no excuse for not having it. The best monitoring setup is the one that exists.
Uptime Kuma: the self-hosted option, used correctly
Uptime Kuma is an open source, self-hosted monitor that runs as a single Docker container. It is genuinely good software. The interface is clean, it handles HTTP, TCP, ping, DNS and keyword checks, it does push monitors for cron jobs, it drives a public status page, and it supports a very long list of notification channels. It is free forever and there is no monitor limit beyond what your server can handle.
It is also light. It sits at roughly 150MB of memory, which is nothing next to the things that actually strain a small VPS. Ours was never the problem. The placement was.
The correct way to run it is on separate infrastructure from the thing being watched. That means a second cheap VPS, ideally with a different provider and in a different data centre, doing nothing but monitoring. The smallest tier at any budget host is enough, because the workload is trivial. Five or six pounds a month buys you an alerting system that is not correlated with the failure it is supposed to report.
That reframes the cost question. Uptime Kuma is not free versus UptimeRobot free, it is the price of a second small server versus UptimeRobot free. What you buy for that money is unlimited monitors, full data ownership, keyword checking, and a status page you control. Whether that is worth it depends on whether you already wanted a second box for other reasons.
Our honest filter: if you are running one or two products, this is not worth the operational overhead. Take the free hosted tier. If you are running a portfolio, already comfortable with Docker, and want a status page without a per-seat bill, Uptime Kuma on its own small server is a good answer. Just never on the box it watches.
Better Stack: when you want it bundled
Better Stack packages uptime monitoring with log management and a status page. The free tier covers 10 monitors at three-minute checks plus 1GB of log ingestion per month. Paid plans start around $24 per month for more monitors, faster intervals, and longer retention.
The uptime product is the strongest thing they make. Three-minute checks on the free tier beats UptimeRobot on interval, the incident handling is more thought through, and the status pages look better than anything you will assemble yourself. If you want an on-call rotation and escalation policies later, the path exists.
The reason to choose it over the free options is consolidation. If you are already going to want log search when something breaks, having uptime alerts and the logs that explain them behind one login removes a real friction at the exact moment you are least patient. Ten free monitors is fewer than UptimeRobot gives you, but ten is enough for most solo portfolios.
The reason not to choose it is that you are paying for breadth you may not use. If you have Sentry for errors and your host already gives you logs, the bundle is solving a problem you do not have yet.
The false confidence problem: 200 OK is not "working"
This is the part that generic monitoring advice skips, and it is the failure we actually shipped.
Our site is a static export. A build succeeded, the deploy ran clean, and the homepage returned 200 to every check. The monitor was green for days. Meanwhile several individual pages were returning 404, because the build had quietly produced no page file for them. Every automated signal we had said the site was healthy. It was not.
An uptime monitor pointed at your homepage tells you your homepage is up. It tells you nothing about the other fifty URLs. If your deploy process can produce a partially broken site, and most can, then homepage-only monitoring is a green light that means very little.
Two fixes, both cheap. First, monitor more than one URL. Add your highest-value pages: the pricing page, the signup flow, one deep article, the API health endpoint if you have one. Free tiers give you enough monitors to cover the pages that matter. Second, use keyword monitoring where the tool supports it. Instead of accepting any 200 response, check that the page body actually contains an expected string. A 200 with a broken template still fails a keyword check, and that catches a whole category of failure that status codes miss.
Better Stack and Uptime Kuma both do keyword checks. UptimeRobot has it on paid tiers. If you only take one thing from this section: a green dashboard is evidence that one URL responded, not that your product works.
Check intervals, alert fatigue, and the 3am problem
Shorter check intervals sound strictly better and are not. A one-minute check on a slightly flaky setup will find transient failures that nobody needed to know about, and it will find them at three in the morning.
The predictable outcome is that you start ignoring the alerts, and an ignored alert is worse than no alert because it carries the illusion of coverage. We have watched this happen on other people's setups and the ending is always the same: notifications muted, real outage missed, monitor quietly deleted six months later.
Practical settings that hold up for a solo portfolio. Five-minute intervals are fine for content sites and small apps. Require two consecutive failures before alerting, which most tools support and which eliminates the majority of false positives from a single dropped request. Send routine alerts to email or a chat channel rather than to your phone, and reserve push or SMS for the one or two properties where downtime genuinely costs you something.
Also monitor from more than one location if the tool offers it. A single check node having a bad minute looks identical to your site being down, and multi-region confirmation removes that class of noise entirely.
What we actually run now
External hosted monitoring for every public property, on a free tier, with five-minute checks and two-failure confirmation before an alert fires. That covers the case the self-hosted setup catastrophically did not: the server itself going away.
More than one URL per site. The homepage, plus the pages that would be expensive to have broken. This came directly out of the 404 incident and is the single highest-value change we made.
Uptime Kuma is still in the stack, but its job changed. It is useful for internal services and for checks we do not want to expose to a third party, and it is a genuinely nice status page. It is no longer the thing we depend on to tell us the estate is on fire.
Error monitoring runs alongside it rather than instead of it, because the two catch different failures. The 404 incident is instructive here too: uptime said fine, and it took a different class of tool and an actual human looking to find it.
Total spend on uptime monitoring: nothing. The free tiers are sufficient at our scale and we have not found a reason to upgrade. The cost was never the money. It was the several hours we spent not knowing.
When you can skip this entirely
If you are building something nobody uses yet, you do not need this. A monitor on a project with no users is a notification system telling you about an outage that affected you alone, and you were going to open the site anyway. Set it up when you share the link publicly, not before.
You also do not need three tools. The comparison above exists because people search for it, not because the answer is complicated. For most solo founders the correct configuration is one free hosted monitor, four or five URLs, and an email address. That is the whole recommendation, and it takes less time than reading this article.
And you do not need a status page until somebody asks where the status page is. Status pages are for reassuring users you already have. If you are building one before you have those users, it is procrastination with a nice interface.
Put a free hosted monitor on every public property today, point it at more than just the homepage, and require two failures before it wakes you. Self-host the monitor only if it lives on separate infrastructure from the thing it watches. The setup takes under ten minutes and the failure it prevents is the one where your site has been down since Tuesday and you are the last to know.
Frequently Asked Questions
Uptime monitoring checks whether your server responds to a request at all, so it catches total outages: the server is down, the certificate expired, the reverse proxy lost the app. Error monitoring watches for failures inside a site that is technically responding, such as JavaScript exceptions or failed database calls. A site can be 100% "up" and completely broken, which is why most setups eventually want both.
Uptime Kuma gives you unlimited monitors, keyword checks, and full data ownership for free, which is more capability than UptimeRobot's free tier. But it is self-hosted, so it only makes sense if you run it on separate infrastructure from the sites it monitors, which means paying for a second small server. For one or two products, hosted UptimeRobot is the lower-effort and more reliable answer. For a portfolio where you already run Docker, Uptime Kuma on its own box is a good choice.
You can, and it will appear to work, but it defeats the purpose. If the server runs out of memory, loses network, or fails to come back after a reboot, the monitor goes down with everything else and no alert is sent. This is exactly what happened to us. Run it on a separate VPS, ideally with a different provider, or use a hosted service instead.
Five minutes is a sensible default for content sites and small apps. One-minute checks generate false positives from transient network blips and lead to alert fatigue, which is more dangerous than a slightly slower detection time because muted alerts miss real outages. Whatever interval you choose, configure the monitor to require two consecutive failures before it alerts you.
Probably not. The free tiers from UptimeRobot and Better Stack cover a solo portfolio comfortably, and we run our own monitoring at zero cost. Paid plans buy shorter check intervals, SMS and phone alerts, keyword monitoring on some providers, and longer history. Upgrade when a few minutes of undetected downtime actually costs you money, not before.