Public beta Monitoring, status pages, on-call and incident evidence
Quietbeat checks your sites, APIs and scheduled jobs, pages whoever is on call, and moves your status page to the right state. Monitors, status pages, and real paging — one flat price, unlimited teammates.
10 monitors free · $9 solo · $19 team — flat, no card required
api.example.com Up
167 ms median
Seven examples
Pick one. The checks, the flight log, who gets woken, the status page and every message that goes out, replayed from example data.
Seven scenarios, each shown in full below — read top to bottom.
A deploy goes wrong and the health endpoint answers 500. The failed availability check is held and re-probed before anyone is paged, then the rota rings, the page is acknowledged, and the recovery is captured.
20 passing checks, then 12 failing, then 4 passing again
The outage of September 14
Assessment · HTTP 500 from the origin
One vantage observed this window — breadth beyond it is unknown.
DNS: ok TCP: ok TLS: ok HTTP: failed
confidence: MEDIUM — The failure signal is specific, but only one vantage observed it — breadth is unverified.
ana@example.com is on-call · until Tue 09:00 CEST
Repeats every 5 min, up to 20 rounds, until someone acknowledges.
All systems up before
4 services monitored, all responding.
Incident in progress 14:32
1 of 4 services affected — details below, updates as they happen.
All systems up 14:37
api.example.com is back — 4 services monitored, all responding.
Subscribers are emailed when it opens and when it resolves.
DOWN 14:31 UTC — api.example.com
api.example.com stopped answering at 14:31 UTC. The probe saw: HTTP 500. Checked: https://api.example.com
DOWN 14:31 UTC — api.example.com
api.example.com stopped answering at 14:31 UTC. The probe saw: HTTP 500. Checked: https://api.example.com
Quietbeat — availability check re-probed before paging
[api.example.com] We're looking into an issue
api.example.com started having trouble at 14:31 UTC. We're on it — updates will follow here and on the status page.
{
"label": "HTTP",
"after": "200",
"recovered": true,
"before": "200",
"changed": true,
"layer": "http",
"during": "500"
}
the HTTP row, before · during · after
api.example.com 99.985% 1 incident
The rota decides who hears it, at the moment the rung fires — not whoever was on call when you wrote the ladder. The page repeats every five minutes, up to 20 rounds, until someone says they have it.
24 passing checks, then 10 timeouts, then 2 passing
The outage of September 14
Assessment · No response within the timeout
One vantage observed this window — breadth beyond it is unknown.
DNS: ok TCP: unknown TLS: unknown HTTP: unknown
confidence: MEDIUM — The failure signal is specific, but only one vantage observed it — breadth is unverified.
ana@example.com is on-call · until Tue 09:00 CEST
Nobody on the rota? The workspace owner is paged — never a void.
All systems up before
4 services monitored, all responding.
Incident in progress 03:12
1 of 4 services affected — details below, updates as they happen.
All systems up 03:41
app.example.com is back — 4 services monitored, all responding.
Subscribers are emailed when it opens and when it resolves.
DOWN 03:11 UTC — app.example.com
app.example.com stopped answering at 03:11 UTC. The probe saw: timeout. Checked: https://app.example.com
[app.example.com] We're looking into an issue
app.example.com started having trouble at 03:11 UTC. We're on it — updates will follow here and on the status page.
[app.example.com] Resolved
app.example.com is back to normal as of 03:41 UTC. Total impact: 29 min.
{
"label": "HTTP",
"after": "200",
"recovered": true,
"before": "200",
"changed": true,
"layer": "http",
"during": "timeout"
}
the HTTP row, before · during · after
app.example.com 99.931% 1 incident
The job pings after every successful run. Silence is not a network fact — no vantage observed a failure — so nothing is re-probed: the incident opens when the window and its grace pass, carrying the last run that did happen.
six nightly runs arrived, the seventh did not
The silence of September 14
Assessment · Heartbeat went silent
No probe observations in the incident window.
confidence: LOW — The evidence identifies a layer but not how far the failure extends.
ana@example.com is on-call · until Tue 09:00 CEST
Every monitor has its own ladder. This one never pages the rota.
All systems up throughout
4 services monitored, all responding.
nightly-backup is internal — it is not on the public page.
MISSED 05:00 UTC — nightly-backup
Nothing heard from nightly-backup since 04:00 UTC. Expected a run at 04:00 UTC (cron "0 4 * * *", +1 h grace). Last run took 5.0s (recent average 4.7s). Last output received: backup ok, 1.9 GB in 5 s
Quietbeat — heartbeat silence; nothing to probe
{
"avg_duration_ms": 4700,
"captured_at": "2026-09-14T05:00:30Z",
"kind": "heartbeat",
"last_beat_at": "2026-09-13T04:00:11Z",
"last_duration_ms": 5000,
"last_payload": "backup ok, 1.9 GB in 5 s"
}
the capture, as the export carries it
nightly-backup 99.461% 1 incident
Four warnings went out — 30, 14, 7 and 1 day before — and nobody renewed. At 09:14 the handshake starts failing, the incident opens, and the assessment names the layer that broke.
the four expiry warnings were sent; 18 passing checks, then 8 failed handshakes
The outage of September 14
Assessment · TLS handshake failure
One vantage observed this window — breadth beyond it is unknown.
DNS: ok TCP: ok TLS: failed HTTP: not reached
confidence: MEDIUM — The failure signal is specific, but only one vantage observed it — breadth is unverified.
ana@example.com is on-call · until Tue 09:00 CEST
The warnings are notices to your configured alert channels. Only the failed handshake opens an incident and climbs the ladder.
All systems up before
4 services monitored, all responding.
Incident in progress 09:15
1 of 4 services affected — details below, updates as they happen.
All systems up 09:31
pay.example.net is back — 4 services monitored, all responding.
Subscribers are emailed when it opens and when it resolves.
CERT 7d — pay.example.net
The TLS certificate for https://pay.example.net expires in 7 days, on 2026-09-14. Renew it before it expires.
DOWN 09:14 UTC — pay.example.net
[pay.example.net] Resolved
pay.example.net is back to normal as of 09:31 UTC. Total impact: 16 min.
pay.example.net 99.962% 1 incident
Every six hours the zone is read back record by record. A change is a finding, not an outage: no incident opens and uptime is untouched, but whoever can edit your zone can take your mail — so you hear about it the same day.
nine record sets read; MX changed, the rest unchanged
| A | 203.0.113.10 | same |
|---|---|---|
| AAAA | 2001:db8::10 | same |
| MX | 10 mx1.example.com | removed |
| MX | 10 mx.mail-relay.example.net | added |
| TXT | v=spf1 include:_spf.example.com -all | same |
| NS | ns1.example-dns.net, ns2.example-dns.net | same |
| CAA | 0 issue "letsencrypt.org" | same |
No incident — a finding
A record changing is not downtime and never touches uptime.
ana@example.com is on-call · until Tue 09:00 CEST
No incident and no on-call ladder: the finding goes to email and to every channel except the pagers.
All systems up throughout
4 services monitored, all responding.
A record change is not an outage — the page stays as it is.
DNS record changed — example.com
The MX record for example.com changed. Added: mx.mail-relay.example.net Removed: mx1.example.com It now reads: 10 mx.mail-relay.example.net It read before: 10 mx1.example.com If this was you, nothing to do. If it was not, treat it as urgent: whoever can edit this zone can receive your mail and get certificates in your name.
Every check still answers 200. After a deploy the rolling p95 climbs past the line you drew, and that is worth a notification — never an incident, so your uptime stays honest.
16 checks around 140 ms, then 10 checks between 520 and 900 ms
No incident — up, but not fine
Slow is a notification. Uptime only counts what failed.
Had it gone down, the incident page would name the deploy: “a3f19c2 · search shipped 10 min before this began”.
ana@example.com is on-call · until Tue 09:00 CEST
No incident and no on-call ladder: the notice goes to your configured alert channels. One notice per hour, at most.
All systems up throughout
4 services monitored, all responding.
Slow is not down — the page stays as it is.
DEGRADED 16:12 UTC — search.example.com
search.example.com is up, but not fine: the 10-minute p95 is 878ms across 10 checks — the line is drawn at 400ms.
a3f19c2 · search · 14 Sep 16:02
marked by one POST from CI — the GitHub Actions tab below
checkout declares Stripe as a dependency, so when the incident opens the latest reading of Stripe's status — under 20 minutes old — is named in the alert: as a lead, never as a reason to hold the page back.
20 passing checks, then 14 failing, then 2 passing
The outage of September 14
Assessment · HTTP 502 from the origin
One vantage observed this window — breadth beyond it is unknown.
DNS: ok TCP: ok TLS: ok HTTP: failed
confidence: MEDIUM — The failure signal is specific, but only one vantage observed it — breadth is unverified.
Declared dependencies, the latest fresh reading when this opened
major Stripe — Partial System Outage
selected because this monitor declares them as dependencies — a lead, not a cause, and never a reason the alert was held back
ana@example.com is on-call · until Tue 09:00 CEST
A vendor outage still pages: your checkout is still down.
All systems up before
4 services monitored, all responding.
Incident in progress 11:02
1 of 4 services affected — details below, updates as they happen.
Incident in progress 11:10 · update posted
Card payments are failing at our payment provider. Checkout is affected; we are following their status page.
All systems up 11:48
4 services monitored, all responding.
Subscribers hear the update you post, word for word.
DOWN 11:02 UTC — checkout.example.com
checkout.example.com stopped answering at 11:02 UTC. Likely vendor involvement: Stripe — partial system outage. The probe saw: HTTP 502. Checked: https://checkout.example.com
[checkout.example.com] Update
Card payments are failing at our payment provider. Checkout is affected; we are following their status page.
{
"label": "HTTP",
"after": "200",
"recovered": true,
"before": "200",
"changed": true,
"layer": "http",
"during": "502"
}
the HTTP row, before · during · after
checkout.example.com 99.893% 1 incident
How it works
A failed check becomes an incident, a page and a status update without anyone opening a laptop first. You answer the page and choose the words.
HTTP, TCP, DNS and certificate checks, plus heartbeats from your scheduled jobs: every 60 seconds on Hobby, as often as every 30 from Team up.
A failed availability check is re-probed before anyone is paged: from an independent vantage when one is online, otherwise a fresh probe moments later. If the target keeps failing while confirmation stays out of reach, the incident opens on the accumulated evidence.
Whoever is on call is paged on the channels they chose, by schedule and rotation. It re-pages up to 20 rounds until someone acknowledges.
Your status page moves to the right state on its own. You write the words when you are ready.
Every incident keeps what was seen: the response, the DNS answers, the TLS state, the timing and which vantages actually observed the failure, exportable as JSON for the postmortem or the vendor ticket. Evidence capture runs on every plan, Hobby included, and the AI summary labels each conclusion a hypothesis and says what it could not see.
Your first signal in 60 seconds
Make a monitor, copy its ping URL, and send it from wherever your work already runs. Every snippet here works against the API today — swap the placeholder for your own token.
curl -fsS https://quietbeat.dev/b/YOUR_PING_TOKENCreate a heartbeat monitor, copy its ping URL, and send the first beat. Anything that can make a request can keep a monitor alive.
# a cron job that reports in — GET or POST, body optional
0 4 * * * backup.sh && curl -fsS https://quietbeat.dev/b/YOUR_PING_TOKENThe beat only goes out when the job succeeds — a night without one opens the incident.
- name: Mark the deploy in Quietbeat
run: |
curl -fsS -X POST https://quietbeat.dev/api/v1/deploys \
-H "Authorization: Bearer ${{ secrets.QUIETBEAT_TOKEN }}" \
-H "Content-Type: application/json" \
-d '{"ref": "${{ github.sha }}", "component": "api"}'The last step of a deploy job. An outage that follows it names the commit that shipped.
HEALTHCHECK --interval=60s --timeout=10s \
CMD curl -fsS http://localhost:8080/health \
&& curl -fsS https://quietbeat.dev/b/YOUR_PING_TOKEN || exit 1The container pings only while its own health endpoint answers. When it stops, so do the beats.
brew install mightyworks-sk/tap/qb
export QB_API_KEY=qb_YOUR_TOKEN
qb monitors create --name "prod site" --kind http \
--url https://example.com/health --interval 60One static binary. --json prints the API response verbatim, for jq and for agents.
terraform {
required_providers {
quietbeat = { source = "mightyworks-sk/quietbeat" }
}
}
provider "quietbeat" {
host = "https://quietbeat.dev"
}
resource "quietbeat_monitor" "nightly_backup" {
name = "nightly backup"
kind = "heartbeat"
interval_seconds = 86400
grace_seconds = 3600
cron_schedule = "0 4 * * *"
schedule_timezone = "Europe/Bratislava"
}
output "backup_ping_url" {
value = quietbeat_monitor.nightly_backup.ping_url
}A heartbeat on a cron schedule, its ping URL an output for the job to use. The token comes from QB_API_KEY.
curl -X POST https://quietbeat.dev/api/v1/monitors \
-H "Authorization: Bearer qb_YOUR_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name": "nightly backup", "kind": "heartbeat",
"interval_seconds": 86400, "grace_seconds": 3600,
"runbook": "check restic logs first"}'The same call the CLI and the Terraform provider make. The answer carries the ping URL.
claude mcp add --transport http quietbeat https://quietbeat.dev/mcp --header "Authorization: Bearer qb_YOUR_TOKEN"
# then, in the session:
# > watch my nightly backup — it runs at 04:00 and takes a few secondsAdd the server once. The agent calls create_monitor and hands back the crontab line.
Pricing
Paid plans differ by scale — monitors, people you can page, history — never by which features you get. Every paid plan starts with a 10-day trial, and annual billing is two months free.
free, no card, no clock
Serious monitoring for one person's projects.
$90/yr — two months free
Every deep check, and a page that repeats.
$190/yr — two months free
On-call for a team that ships to production.
$490/yr — two months free
The whole engineering org on one rota.
$990/yr — two months free
Fleet-sized monitoring, same flat bill.
Commercial use welcome on every plan · No price change without 30 days' notice · cancel anytime · annual billing = 2 months free · no metered check-volume charges · Compare every limit
10 monitors free, no card required · runs in the EU (Germany)
Leave anything. One-paste importers bring your monitors across from UptimeRobot, Better Stack, Pingdom, StatusCake, Healthchecks.io, Oh Dear, Opsgenie and Larm with names, intervals and heartbeats intact, in about two minutes.
Built for agents. Everything in the UI is a REST API and an MCP server; shipping an app an AI wrote? Monitoring for AI-built apps.
Connection lost
Attempting to reconnect
Something went wrong!
Attempting to reconnect