Comment nous t'informons ou t'alertons
Une panne ne vaut la peine d'être détectée que si la bonne personne en est informée. Nous envoyons là où ton équipe regarde déjà, et à tes propres systèmes quand une personne ne doit pas être la première à réagir.
Les canaux
Chaque canal reçoit le même message : quel monitor, depuis quand et pourquoi. Chacun est une adresse que tu ajoutes une fois et que tu nommes ensuite dans une règle.
-
Email Chaque forfait
Un message à n'importe quelle adresse, confirmé une fois avant que nous envoyions, pour qu'une alerte ne puisse pas être dirigée vers la boîte mail de quelqu'un d'autre.
-
Webhook (POST) Chaque forfait
Un corps JSON avec tous les champs ci-dessous, vers une URL à toi. Pour ton automatisation : ouvrir un ticket, alerter une rotation, changer une lumière de statut.
-
Webhook (GET) Chaque forfait
Les mêmes champs en paramètres de requête, pour un récepteur qui ne peut accepter qu'un GET.
-
PagerDuty Starter et plus
Un incident via l'Events API v2, ouvert lors d'une panne et résolu lors du rétablissement, pour que l'escalade propre à PagerDuty prenne le relais. Un check lent ou avec des pertes arrive comme un avertissement, pas comme critique.
-
Slack Pro et Business
Un message dans un canal, rouge pour une panne et vert pour un rétablissement, via un webhook.
-
Microsoft Teams Pro et Business
Le même message dans un canal Teams, via un webhook.
-
Discord Pro et Business
Le même message dans un canal Discord, via un webhook de canal.
-
Telegram Pro et Business
Le même message dans un chat, via ton propre bot.
Qui entend quoi, et quand
Confirmé en premier
Rien n'est envoyé sur la seule parole d'une sonde. Une défaillance devient une panne quand des sondes sur deux autres continents sont d'accord, donc une alerte signifie que le site est en panne et non un réseau intermédiaire.
Règles et escalade
Une règle indique qui entend parler de quels monitors et combien de temps après le début de la panne. Mets la rotation d'astreinte dans un groupe de contacts avec un délai par membre, et une règle devient une escalade qui s'arrête dès que le monitor se rétablit.
Rétabli, dit une fois
Tout le monde informé de la panne est informé quand elle se termine, avec sa durée. Nous ne te réveillerons pas pour te dire que la panne est finie.
Teste avant d'en avoir besoin
Chaque adresse a un bouton qui envoie un test par le même chemin qu'une vraie alerte, formulé pour ne pas être pris pour une vraie panne.
Le webhook, pour tes propres systèmes
Une adresse webhook est une URL à toi. On l'appelle quand une panne est confirmée, quand elle se termine, et quand tu appuies sur tester. POST envoie les champs dans un corps JSON ; GET les envoie comme paramètres de requête. L'URL est stockée chiffrée et n'est plus jamais affichée en entier, car quiconque la possède peut y envoyer des requêtes.
| Champ | Ce qu'il contient |
|---|---|
| reason | down quand une panne est confirmée, recovery quand elle se termine, test quand quelqu'un a appuyé sur le bouton |
| monitor | Le nom du monitor |
| monitor_id | Son id, le même que dans son adresse sur le tableau de bord |
| target | Ce qu'il vérifie : l'URL, l'hôte ou le nom |
| type | Le type de vérification, sous un nom court comme https, dns ou ssl_cert |
| cause | Pourquoi il a échoué, en quelques mots, quand on le sait |
| error_class | La même chose sous un nom court qu'un programme peut utiliser, comme timeout, connection ou certificate_expired |
| started | Quand la panne a commencé, comme une heure avec son fuseau |
| confirmed_at | Quand l'échec a été confirmé |
| confirmed_from | Les continents qui l'ont confirmé, sous forme de liste de noms. C'était un seul nom jusqu'en septembre 2026 |
| degraded | true quand le monitor est lent ou perd des paquets plutôt que down |
| resolved | Quand elle s'est terminée, comme un timestamp ISO 8601, lors d'une recovery |
| duration | Combien de temps elle a duré, en toutes lettres, lors d'une recovery |
| incident_id | L'id de l'incident, le même pour la panne et sa recovery |
Un champ sans contenu est null dans le JSON et omis dans un GET. Réponds avec un statut en dessous de 400. Tout autre chose est considérée comme un échec de livraison et sera réessayée après 30 secondes, 2 minutes et 10 minutes, puis abandonnée : une alerte qui n'est pas arrivée dans le quart d'heure est de l'histoire, pas une nouvelle.