For DevOps and SRE

Checks that fail twice before they wake you

Thresholds you set, incidents that open themselves, heartbeats for the jobs nobody watches, a signed webhook for every event, and a status page that updates without anyone touching it. Built for the person on call.

Start freeSee the webhook events

Free for one monitor. No card needed.

Checkout APIOutage · 17 min
  1. 02:14:05

    Check failed: HTTP 503 after 1 840 ms

  2. 02:14:35

    Failed again. Two in a row is your threshold, so this is real.

  3. 02:14:36

    Incident opened from the monitor rule: “Checkout errors”, Investigating

  4. 02:14:37

    Posted to Slack #ops, webhook sent to your pager, 912 subscribers emailed

  5. 02:31:40

    Two checks passed in a row

  6. 02:31:41

    Incident moved to Monitoring. You resolve it when you are sure.

30s
Fastest check
6
Monitor types
13
Webhook events
N
Failures before an alert, your call

02:14, and what happened next

The parts of an incident that should not need a person.

02:14

The check fails, then fails again

One failure is noise. Your threshold is two in a row, so the second one is the alert. Same rule on the way back up: two passes before anything is called recovered.

02:15

The incident opens itself

The rule on the monitor publishes an incident from your template, sets the component to Outage and notifies subscribers. Customers know before you are awake.

02:32

Recovery is verified, not assumed

Passing checks move the incident to Monitoring, not Resolved. You write the last update when you have actually read the logs.

Heartbeats for the jobs nobody watches

Backups, exports, queue drains, certificate renewals. A heartbeat monitor gives each job a URL to ping when it finishes. Miss one and a half intervals and it is down, with the same alerting as everything else.

  • One curl at the end of the script; the token is shown once
  • Works for anything inside your network, because the job calls out to us
  • Sits in the same list as your HTTPS and TCP checks
Monitors4 up · 1 down
  • Nightly export
    Heartbeat · every 24 h
    3 h ago
  • Queue drain
    Heartbeat · every 5 min
    1 min ago
  • Backup to S3
    Heartbeat · every 1 h
    94 min ago
  • db.tidepool.io:5432
    TCP · every 1 min
    41 ms
  • api.tidepool.io/health
    HTTPS · every 30s
    96 ms

A webhook for every event

Thirteen event types, signed with a secret you see once, retried when your endpoint is down. Route monitor.down to your pager, incident.created to a war-room channel, maintenance.started to the deploy bot.

  • Payloads carry the monitor, the error and the failure count
  • API keys for reading and writing everything the dashboard can
  • Audit log of who changed what, for the retro
Outbound webhooks13 events
Incidents
  • incident.created
  • incident.updated
  • incident.resolved
Maintenance
  • maintenance.scheduled
  • maintenance.reminder
  • maintenance.started
  • maintenance.completed
Monitors
  • monitor.down
  • monitor.up
  • monitor.ssl_expiring
Pages
  • component.status_changed
  • page.published
  • subscriber.created
{
  "event": "monitor.down",
  "monitor": { "name": "Checkout API", "type": "http" },
  "error": "HTTP 503",
  "failed_checks": 2,
  "occurred_at": "2026-09-14T02:14:35Z"
}

Every delivery is signed with a secret you see once. Failed deliveries are retried.

Maintenance windows for the deploys you planned

Schedule the window, name the components, and the page shows Maintenance instead of Outage while you work. Subscribers get reminders before, and a note when it is done.

  • Reminders at 24 h and 1 h by default; change them per window
  • Start early or finish late from the dashboard, and the page follows
  • maintenance.started fires a webhook, so your own tooling can go quiet too
Kubernetes upgradeScheduled
Sat 19 Sep, 01:00to02:30 UTC

Reports may be a few minutes late. Nothing is lost; queued work runs when the window closes.

AffectsReporting APIWebhook delivery
Subscribers hear about it 24 h before, 1 h before, when it starts, when it ends.

The checks on-call teams lean on

The service, the port under it, and the certificate in front of it.

HTTPS monitoring

Request a URL every 30 seconds and check the answer, not just the status code.

About https monitoring

TCP monitoring

Databases, mail servers, game servers: anything with a port.

About tcp monitoring

SSL expiry monitoring

Reminders at 30, 14, 7 and 1 days, plus a check of the whole chain.

About ssl expiry monitoring

Questions from engineers

Let the page take the first call.

One monitor and a status page, free. No card needed.

Start monitoring