Monitoring you cannot automate goes stale.
Monitors you click together drift out of date by the next sprint. Here, every monitor is a JSON endpoint, so your pipeline keeps monitoring honest.
Built for the way ops teams actually work.
Uptime checks, from outside
HTTP checks from 6 regions at intervals down to 30 seconds, with incident history you can query over the same API the dashboard uses.
Learn moreDead-man's switches for cron
Give every cron job and queue worker a heartbeat URL to curl on success. When the ping stops arriving, an incident opens. Silence becomes a page.
Learn moreServer metrics, push only
A monitored server pushes its own CPU and memory samples to a tokened endpoint on its own cron cadence. Nothing polls it, so there is no inbound port to open.
Learn moreYour /health route, enforced
Your app decides what healthy means in a route. A health monitor calls it from outside on a schedule, keeps the history, and owns the alerting.
Learn moreThe ports behind the app
TCP checks on Postgres, Redis, and SMTP catch infrastructure failures directly, before they surface as a wall of application errors.
Learn moreAlerts that fit the rotation
PagerDuty, Opsgenie, ntfy, Slack, and signed webhooks. Route each monitor to the channel that should wake up, not one firehose for everything.
Learn moreEverything is an API. The dashboard is just a client.
Ship a new service and its monitor in the same pipeline run: one POST creates the monitor, a second one triggers an immediate out-of-band check, so the deploy job itself confirms the service answers from the outside before it reports green.
Incidents and status pages are the same story: plain JSON, no separate "automation tier". If the dashboard can do it, curl can do it.
# deploy.sh: register the service you just shipped curl -X POST https://uptime-status.org/api/monitors \ -H "Authorization: Bearer $API_TOKEN" \ -d '{ "name": "orders-api", "url": "https://api.example.com/health" }' # then verify it answers, right now, out of band curl -X POST https://uptime-status.org/api/monitors/42/check \ -H "Authorization: Bearer $API_TOKEN"
The backup that fails loudly is not the problem.
The one that silently stops running is. A heartbeat monitor inverts the logic: your script curls a ping URL as its last line, on the success path only, and UptimeStatus alerts when the ping stops arriving within the grace period.
The same pattern covers queue workers, certificate renewal jobs, and anything else that only fails by going quiet. See cron & heartbeat monitoring.
#!/bin/sh # nightly-backup.sh pg_dump "$DATABASE_URL" | gzip > /backups/db-$(date +%F).sql.gz # last line, success path only: report in curl -fsS https://uptime-status.org/api/ping/your-token
MIT licensed. Run it inside the fence.
Clone it and run the whole product inside your own network, no license keys, no phone-home. One honest caveat from us: a monitor inside a failing network cannot report that failure, so pair a self-hosted install with an external region watching from the outside.
Ops questions, answered.
How much can I actually do over the API?
Everything the dashboard does goes through the same JSON endpoints: monitors, incidents, and status pages are all plain CRUD. There are also purpose-built routes for automation, like POST /api/monitors/{id}/check to trigger an out-of-band check and POST /api/incidents/{id}/acknowledge for one-step acks from a bot.
What do I need to self-host it?
It is a Stacks application running on Bun, with SQLite as the default database. Clone the repo, run bun install and ./buddy serve, and you have the full product, MIT licensed. No Kubernetes, no external services required to start.
What does a webhook payload look like?
A JSON body with event, data, and timestamp fields, POSTed with an X-Webhook-Event header naming the event and an X-Webhook-Signature header carrying an HMAC SHA-256 of the body, keyed with your subscription secret. Failed deliveries are retried 3 times with backoff, and each subscriber is delivered to independently so one slow endpoint cannot block the rest.
Can different monitors page different people?
Yes. Notification channels are assigned per monitor, so the database TCP check can page the on-call SRE through PagerDuty while a staging monitor just posts to Slack. Test-sends are built in, so you can verify a channel before trusting it with a 3am page.
Is there a Terraform provider or Kubernetes operator?
No, and we would rather be honest about that than list them as "coming soon". The automation story is the JSON API: a curl in your deploy pipeline creates or verifies monitors, and because the API covers everything, wrapping it in whatever tooling you already run is straightforward.
Start monitoring in under 2 minutes.
No credit card required for the self-hosted, open-source version.