Hosted uptime monitoring, powered by Uptime Kuma, with down alerts confirmed by probes in three regions before anyone gets paged.
Each customer gets their own instance of Uptime Kuma 2.5.11, running in its own container with its own SQLite database. The container is capped at 512 MB of memory and half a CPU, and it used about 200 MB of RAM in our testing. Your monitors, your notification channels, and your data live in that instance, and backups of the database are taken daily and kept for fourteen days. The fork we run is public, the upstream MIT licence notices are intact, and you can take your data and self host the same software if you ever leave.
The price is flat: $10 a month or $75 a year, in US dollars, with a 14 day trial. There is no per-monitor metering and no per-seat metering.
A monitor that runs in one place has one point of view. When the route between that place and your server breaks, the monitor sees a healthy site as down and sends an alert. Upstream Uptime Kuma was asked for regional monitoring nodes in issue #1915, and that request was closed as not planned. We built the layer outside the instance instead.
When a customer instance reports a target as down, the event goes to a confirmation service rather than straight to the customer. Probe nodes in three regions (us-east, eu-central, and ap-southeast) each fetch the target from their own network. The alert is forwarded only when at least two of the three probes also report the target as down. When the vote falls short, the event is logged as a suppressed false alarm and no alert goes out. In the customer instance, the monitor's webhook notification points at the confirmation service, and the service forwards confirmed alerts to the customer's own alert endpoint.
Try the vote. Click a region to flip what that probe reports, and watch the outcome.
0 of 3 probes report down. No alert.
A status page matters most during an outage, and an outage can take the machine behind the page with it. Each public status page is mirrored to static files on separate infrastructure. The mirror holds a copy of the page with its scripts removed, plus a JSON snapshot of the monitor states and the time the snapshot was taken, so the page keeps answering even when the instance and its region are gone.
There is an importer for UptimeRobot exports. It reads the API v2 JSON export and CSV exports, and it converts HTTP, keyword, ping, port, and push monitors into the matching types here. The honest limits: check intervals under 60 seconds are clamped to 60 seconds and the clamp is reported back to you, an import is capped at 100 monitors, and push monitors get a new push token, so heartbeat jobs have to be repointed at the new address. UptimeRobot exports carry no notification channels, so channels are added by hand after the import finishes.
Published because the product asks you to trust it with your 3 a.m. alerts, and the economics are part of that trust. These are measured and estimated figures from our own build, stated as of November 2026.
| Item | Figure |
|---|---|
| Infrastructure at 100 customers | about $145 per month |
| Total unit cost per customer per month, including the Stripe fee | about $2.04 |
| Price | $10 per month, or $75 per year |
| Gross margin at that price | about 80 percent |
The service monitors its own infrastructure, the control plane and the three probe regions, and its fleet uptime record will be published on its own status page. It also monitors 5Quotes (5quotes.ca) from day one.