Hosted Uptime Kuma
DownForReal runs Uptime Kuma on our fleet and hands you the finished thing: your own instance with your own database, your monitors checking around the clock, and a confirmation layer that re-checks every down alert from three regions before it pages you. The server underneath, with its updates, certificates, and backups, belongs to us.
What you get
Self-hosting Uptime Kuma means keeping a second system alive so it can tell you when the first one dies, and that second system quietly becomes one more thing that can fail at the wrong moment. Hosting moves that burden onto the operator whose whole job it is.
Every customer runs in a separate instance with a separate database, so your monitors, your history, and your alert settings live in a place that belongs to your account alone and never mixes with another customer's data.
We handle the host, the updates, the TLS certificates, and the daily backups, and fleet improvements roll out centrally, so the version you run stays current without an evening of your time going into it.
Stock Kuma alerts on the word of the one place it checks from. Here, probes in New York, Frankfurt, and Singapore re-check every down result, and at least two of the three must agree before the alert fires.
The two additions
Multi-location checking is the oldest open request in the Uptime Kuma project. Issue #1915 asked for it in 2021 and was closed as not planned, so DownForReal adds it in the notification path, where a confirmed result can still stop an alert before it leaves.
When your instance reports a monitor down, the three probes check the same address at the same moment, and the alert goes out only on a 2-of-3 agreement. When the vote fails to confirm, the alert is held back and the suppression is written into your own instance as a log entry you can read, so every decision the system makes on your behalf stays auditable. You can watch the same vote run against any public site on the free checker.
Status pages are copied off the tenant host onto separate infrastructure on a schedule, so the page your customers read during an incident never sits on the machine that is having the incident. Our own public status page runs on exactly this mirroring, and you can watch it at status.downforreal.com, where it tracks our fleet and a customer site alongside it.
The fork that runs this service is public on GitHub under the MIT licence, and your data lives in a SQLite database inside your own instance. If you ever decide to self-host again, you can take the same software and your own data and run the stack on your own server, which means the trust a hosted monitor asks for never has to rest on our say-so alone. Read the code at github.com/heavyreading/downforreal.
Pricing
There are no per-monitor meters and no per-seat charges to model before you can predict the bill, and the trial runs the full plan for 14 days.
Or $75 a year on the annual plan, which brings the same plan down to $6.25 a month across the year.
Up to 100 monitors at a 60-second minimum interval, down alerts confirmed by the three-region vote, status pages mirrored off-site, the UptimeRobot importer for your existing list, and email support from the operator who runs the fleet.
Coming from UptimeRobot? The switching page walks through the import, including the one manual step.