Trust is the product. Monitor it.
Every blip makes a customer ask “is it down?” Catch outages in 30 seconds, watch the jobs that bill people, and let your status page answer first.
Cover the whole surface your customers feel.
Checks every 30 seconds
On the Pro plan, monitors run as often as every 30 seconds across 6 regions, so a real outage is caught in under a minute, not in a support ticket.
Learn moreA status page that answers for you
A public page with real uptime history, incident updates, subscriber emails, and an RSS feed. The “is it down?” tickets go there instead of to support.
Learn moreHeartbeats on revenue jobs
Billing runs, digest emails, and queue workers fail silently. A heartbeat monitor opens an incident the moment the ping stops arriving.
Learn moreDeeper than HTTP 200
Your app can return 200 while the queue is stuck. Health monitors call a JSON health route and alert on the exact check that flipped.
Learn moreCatch the slow ramp
Latency creeps long before it breaks. Performance history shows the ramp while it is still an engineering task, not a churn number.
Learn moreOn-call, properly paged
Route incidents to PagerDuty or Opsgenie for whoever is on call, and to Slack or Discord for everyone else. 10 channel types, attached per monitor.
Learn moreYour users subscribe once. Support stops explaining outages.
Give customers one page with live component status and real uptime history. Anyone can subscribe by email, and every incident update you post reaches them without a support thread, with a one-click unsubscribe in every mail.
The same updates ship as an RSS feed, so the customers who pipe status into their own tooling get it too. See status pages.
The billing cron that fails quietly costs the most.
A crashed web server pages everyone. A billing job that silently stops running costs you a week of invoices before anyone notices. Heartbeat monitors flip that: silence itself becomes the alert.
Ping only on the success path, so a job that runs but fails still opens an incident. See cron & heartbeat monitoring.
# crontab on your app server 0 2 * * * bin/run-billing \ && curl -fsS https://uptime-status.org/api/ping/your-token # job ran and succeeded: ping arrives, all quiet # job failed or never ran: no ping, incident opens
Your incident data is yours.
UptimeStatus is open source under MIT. Everything sits behind a plain JSON API, so you can export your history any time, and when compliance asks where the uptime data lives, the answer can be your own VPC. Hosted is $9 per month when you would rather not run it.
SaaS questions, answered.
How quickly will we know about an outage?
Free-plan monitors check every 5 minutes; Pro goes as low as every 30 seconds, from 6 regions, with 90 days of history. Failures open an incident and notify your channels immediately, so detection time is roughly your check interval.
Can customers subscribe to status updates?
Yes. Your status page has an email subscribe form, and every incident update you post is mailed to subscribers with a one-click unsubscribe link. There is also an RSS feed at /status/your-slug/feed for people and tools that prefer to poll.
Can we monitor billing crons and queue workers?
That is what heartbeat monitors are for. Add a curl to the monitor's ping URL as the last step of the job, on the success path only. If the ping stops arriving within the grace period, an incident opens and on-call gets paged.
What is the difference between uptime and health checks?
An uptime monitor asks one question: does the URL respond correctly. A health monitor calls a route your app exposes that reports named checks, like database, queue, and storage, and alerts when any one of them flips, even while the homepage still loads fine.
Can we self-host inside our own VPC?
Yes. The whole product is MIT licensed: clone it, run bun install and ./buddy serve, and your uptime history never leaves your network. One caveat: keep an external check somewhere, because a monitor inside a failing network cannot report the failure.
Start monitoring in under 2 minutes.
No credit card required for the self-hosted, open-source version.