Uptime checks that outlive your server
Paste a URL. You get the status code, the response time, the certificate expiry and the redirect chain. No account, five checks an hour.
Five-minute checks
Email, Telegram, Slack, Discord, webhooks
One public status page
Germany and Finland
02 / The problem
It lives on the box it watches
The first is self-hosting it next to the thing it watches. Uptime Kuma in a container on the same box as your app is a dashboard, not a monitor. The host runs out of memory and both go down. The disk fills and both go down. The provider reboots the node and both come back together, with nothing recorded in between, because the only witness was also unconscious.
It is a free tier
The second is a free tier. They cap the number of checks and the interval, and their terms are usually written for personal use, which is a problem the day the side project starts invoicing. Neither cap is unreasonable. They are just not a foundation.
your server, 03:14
app.example.com no route to host
uptime-kuma no route to host
alerts sent: 0
Both processes were on the same machine. Nothing was wrong with either of them.
03 / What it checks
Each one is a condition that either holds or does not, evaluated every five minutes.
A request completes and comes back with a status code you named, inside a timeout you set. Redirects are followed and counted.
A 200 with an error page in the body is still an outage. Name a string that has to be there.
The inverse, for when failure has a signature. A stack trace rendered to the page counts as down.
Read on every check. You hear about it a fortnight out, then again at three days, then on the day.
Checked daily. Auto-renew fails quietly when a card expires, and the domain is gone before anyone notices.
For work with no URL to poll. Your cron job calls us when it finishes; we alert when the call does not arrive.
04 / Alerts
A check that fails once has usually not failed. We retry twice, thirty seconds apart, and only then decide something is wrong.
You get one message when an incident opens and one when it closes, with the duration. Not one per failed check. A four-hour outage is two messages, which is the difference between an alert you read and a channel you mute.
Where they go
The webhook POSTs the incident as JSON to any URL you give us, which is how you connect anything this list does not cover.
Telegram
Resolved — api.example.com
Down 27 min, 12:05 to 12:31 UTC.
Now 200 OK in 240 ms.
05 / Status pages
One public page per account, at a URL you choose. It shows the checks you mark public, the last ninety days, and the incidents as they were recorded, with no way to edit history after the fact.
It is served from the same place the checks run, which means it stays up when you do not. That is the whole point of it.
Ninety days, oldest on the left
06 / Pricing
The number on each plan is how many monitors you can have running at once. Changing an interval never changes your bill.
Solo
20 monitors
A couple of projects and the things around them that can expire.
€9
a month
+20 monitors running at once
+Every monitor type, including heartbeats
+1 public status page
+30 days of history
Saved. Check your inbox.
One email when Solo opens. Nothing before then.
Studio
100 monitors
A client portfolio, or everything you run including the jobs nobody watches.
€29
a month
+100 monitors running at once
+Every monitor type, including heartbeats
+1 public status page
+90 days of history
Saved. Check your inbox.
One email when Studio opens. Nothing before then.
Best effort, no SLA.
We do not offer credits and we do not promise a number. If your business needs a contractual guarantee, buy one from someone who sells it.
Nothing that rings.
We do not send SMS, place phone calls, or run an on-call rotation. If an outage has to wake someone who is asleep, point a webhook at something that pages and build that part yourself.
Five minutes is the floor.
No plan checks faster, at any price. A short outage between two checks is one we will never see.
07 / Honest comparison
Uptime Kuma is genuinely good software and it is free. If you are willing to run it on a machine separate from the one you are watching, it will do more than we do. This table is here so you can decide against us quickly.
| IsMyAppUp | Uptime Kuma, self-hosted | UptimeRobot free | |
|---|---|---|---|
| Runs on | Our machines, in a different data centre from yours | A machine you own and pay for | Their machines |
| Price | €9 or €29 a month | Free software, plus whatever the server costs | Free |
| Notices when your server dies | Yes | Only if it is not on that server | Yes |
| Fastest interval | 5 minutes | Down to 20 seconds | 5 minutes |
| Alert channels | Email, Telegram, Slack, Discord and generic webhooks | Ninety-odd, including SMS gateways, Matrix, ntfy, Pushover | Email, and more on paid plans |
| Status pages | One per account | Unlimited, fully themeable | Yes |
| Upgrades and backups | Ours | Yours | Theirs |
| Commercial use | Yes | Yes | Read their terms before you rely on it |
08 / Questions
Where do the checks run from?
Servers in Germany and Finland, on infrastructure we do not share with the parts of our own stack that serve this website. A check is only useful if it fails independently of the thing it is checking.
What happens when your service goes down?
You get no alerts, and you should assume that is possible. There is no SLA and we will not pretend otherwise at this size. Our own status page is in the footer, and the checks that watch us run somewhere else again.
Why should I pay when Uptime Kuma is free?
Often you should not. If you already run a box that is separate from the thing you want to watch, and you do not mind maintaining one more service, Uptime Kuma is better software than this and it costs nothing. Pay us when you do not want a second box to look after.
Which alert channels do you support?
Email, Telegram, Slack, Discord, and a generic webhook that POSTs the incident as JSON to any URL you give us. We do not send SMS, place phone calls, or run an on-call rotation ourselves. The webhook is the escape hatch: if you need paging, point it at something that pages.
How quickly will I hear about an outage?
Checks run every five minutes and we retry twice, thirty seconds apart, before alerting. In practice that is five to seven minutes from the first failure. If you need sub-minute detection, this is the wrong product.
What do you keep?
The URLs you ask us to check, their results, your email address, and the channel or chat id for any Telegram, Slack or Discord destination you connect. Response bodies are read for keyword matching and then discarded, never stored.