How we inform or alert you
An outage is only worth detecting if the right persons hears about it. We send notifications to where your team already is and to your own systems via webhooks.
The channels
Every channel gets the same message: which monitor, since when and why. Below you find a list of available channels.
-
Email Every plan
A message to any address. The e-mail address needs to be confirmed once.
-
Webhook (POST) Every plan
A JSON body with the relevant data posted to a URL you provided. For your own automation: open a ticket, page a person, flip a status light.
-
Webhook (GET) Every plan
The same fields as the POST webhook but now as query parameters, for a receiver that takes a GET request.
-
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.
-
Slack Pro and Business
A message in a channel, red for down and green for back up, through a webhook.
-
Microsoft Teams Pro and Business
The same message in a Teams channel, through a 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 probes on three continents agree, so an alert means the site is down rather than a network glitch.
Rules and escalation
A rule describes who hears about which monitors and at what time. Put the on-call list in a contact group with a delay per member. This works as your escalation policy.
Back up, said once
Everybody who was told about the outage is told when it ends, with how long it lasted. We will not wake you to tell you the outage 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 a real 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 |
| 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 |
| error_class | The same thing as a short name a program can branch on, such as timeout, connection or certificate_expired |
| started | When the outage started |
| confirmed_at | When the failure was confirmed |
| confirmed_from | The continents that confirmed it, as a list of names. |
| 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 no value is null in the JSON and left out of a GET. You must 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.