Hoe we je informeren of waarschuwen
Een storing is alleen de moeite waard om te detecteren als de juiste personen het horen. We sturen meldingen naar waar je team al is en naar je eigen systemen via webhooks.
De kanalen
Elk kanaal krijgt hetzelfde bericht: welke monitor, since wanneer en waarom. Hieronder vind je een lijst met beschikbare kanalen.
-
Email Elk abonnement
Een bericht naar elk adres. Het e-mailadres moet eenmalig worden bevestigd.
-
Webhook (POST) Elk abonnement
Een JSON-body met de relevante gegevens naar een URL die je hebt opgegeven. Voor je eigen automatisering: open een ticket, roep een persoon op, zet een statuslampje om.
-
Webhook (GET) Elk abonnement
Dezelfde velden als de POST-webhook maar nu als queryparameters, voor een ontvanger die een GET-verzoek accepteert.
-
PagerDuty Starter en hoger
Een incident via de Events API v2, geopend bij een storing en opgelost bij herstel, zodat PagerDuty's eigen escalatie het verder afhandelt.
-
Slack Pro en Business
Een bericht in een kanaal, rood voor down en groen voor weer up, via een webhook.
-
Microsoft Teams Pro en Business
Hetzelfde bericht in een Teams-kanaal, via een webhook.
-
Discord Pro en Business
Hetzelfde bericht in een Discord-kanaal, via een kanaal-webhook.
-
Telegram Pro en Business
Hetzelfde bericht in een chat, via je eigen bot.
Wie hoort wat, en wanneer
Eerst bevestigen
Niets wordt verstuurd op basis van één probe. Een storing wordt een outage wanneer probes op drie continenten het eens zijn, dus een alert betekent dat de site offline is en niet een netwerkprobleem.
Regels en escalaties
Een regel beschrijft wie hoort over welke monitors en op welk tijdstip. Zet de on-call lijst in een contactgroep met een vertraging per lid. Dit werkt als je escalatiebeleid.
Back-up, één keer gezegd
Iedereen die over de storing is geïnformeerd, hoort wanneer het eindigt en hoe lang het duurde. We maken je niet wakker om te zeggen dat de storing voorbij is.
Test voordat je het nodig hebt
Elk adres heeft een knop die een test stuurt via hetzelfde pad als een echte alert, geformuleerd zodat het niet kan worden verward met een echte storing.
De webhook, voor je eigen systemen
Een webhook-adres is een URL van jou. We roepen het aan wanneer een storing wordt bevestigd, wanneer het herstelt en wanneer je op test drukt. POST stuurt de velden als een JSON-body; GET stuurt ze als queryparameters. De URL wordt versleuteld opgeslagen en nooit meer volledig getoond, omdat iedereen die het heeft ernaar kan posten.
| Veld | Wat het bevat |
|---|---|
| reason | down wanneer een storing is bevestigd, recovery wanneer het eindigt, test wanneer iemand op de knop heeft gedrukt |
| monitor | De naam van de monitor |
| monitor_id | Zijn id |
| target | Wat het controleert: de URL, host of naam |
| type | Het type check, als een korte naam zoals https, dns of ssl_cert |
| cause | Waarom het faalde, in een paar woorden, als we het weten |
| error_class | Hetzelfde als een korte naam waarop een programma kan vertakken, zoals timeout, connection of certificate_expired |
| started | Wanneer de storing begon |
| confirmed_at | Wanneer de storing werd bevestigd |
| confirmed_from | De continenten die het bevestigden, als een lijst van namen. |
| degraded | true wanneer de monitor traag is of pakketten verliest in plaats van down |
| resolved | Wanneer het eindigde, als een ISO 8601-timestamp, bij een recovery |
| duration | Hoe lang het duurde, in woorden, bij een recovery |
| incident_id | De id van het incident, dezelfde bij de outage en de recovery |
Een veld zonder waarde is null in de JSON en wordt weggelaten bij een GET. Je moet antwoorden met elke status onder 400. Alles daarboven telt als een mislukte levering en wordt opnieuw geprobeerd na 30 seconden, 2 minuten en 10 minuten, waarna het opgegeven wordt: een alert die niet binnen een kwartier aankomt is geschiedenis, geen nieuws.