Where the alert goes
An outage is only worth detecting if the right person hears about it. We send to where your team already looks, and to your own systems when a person is not the first thing that should react.
The channels
Every channel gets the same message: which monitor, since when, why, and the continent that confirmed it. Each is an address you add once and then name in a rule.
-
Email Every plan
A message to any address, confirmed once before we send to it, so an alert cannot be pointed at somebody else's inbox.
-
Webhook (POST) Every plan
A JSON body with every field below, to a URL of yours. For your own automation: open a ticket, page a rota, flip a status light.
-
Webhook (GET) Every plan
The same fields as query parameters, for a receiver that can only take a GET.
-
PagerDuty Starter and up
An incident through the Events API v2, opened on an outage and resolved on the recovery, so PagerDuty's own escalation takes it from there. A slow or lossy check arrives as a warning, not a critical.
-
Slack Pro and Business
A message in a channel, red for down and green for back up, through an incoming webhook.
-
Microsoft Teams Pro and Business
The same message in a Teams channel, through an incoming webhook.
-
Discord Pro and Business
The same message in a Discord channel, through a channel webhook.
-
Telegram Pro and Business
The same message in a chat, through your own bot.
Who hears about what, and when
Confirmed first
Nothing is sent on one probe's say-so. A failure becomes an outage when a probe on another continent agrees, so an alert means the site is down rather than a network in between.
Rules and escalation
A rule says who hears about which monitors and how long after the outage starts. Put the on-call rota in a contact group with a delay per member, and one rule becomes an escalation that stops the moment the monitor recovers.
Back up, said once
Everybody who was told about the outage is told when it ends, with how long it lasted. Nobody who was never woken is woken to hear it is over.
Test before you need it
Every address has a button that sends a test through the same path a real alert takes, worded so it cannot be mistaken for an outage.
The webhook, for your own systems
A webhook address is a URL of yours. We call it when an outage is confirmed, when it recovers, and when you press test. POST sends the fields as a JSON body; GET sends them as query parameters. The URL is stored encrypted and never shown in full again, because whoever holds it can post to it.
| Field | What it holds |
|---|---|
| reason | down when an outage is confirmed, recovery when it ends, test when somebody pressed the button |
| monitor | The monitor's name |
| monitor_id | Its id, the same one in its address in the dashboard |
| target | What it checks: the URL, host or name |
| type | The kind of check, as a short name such as https, dns or ssl_cert |
| cause | Why it failed, in a few words, when we know |
| started | When the outage started, as a time of day with its zone |
| confirmed_at | When a second continent confirmed it |
| confirmed_from | Which continent confirmed it |
| degraded | true when the monitor is slow or losing packets rather than down |
| resolved | When it ended, as an ISO 8601 timestamp, on a recovery |
| duration | How long it lasted, in words, on a recovery |
| incident_id | The incident's id, the same on the outage and its recovery |
A field with nothing to say is null in the JSON and left out of a GET. Answer with any status below 400. Anything else counts as a failed delivery and is tried again after 30 seconds, 2 minutes and 10 minutes, then given up: an alert that has not landed within a quarter of an hour is history, not news.