Comment fonctionne l'alerting

Comment l’Alerting est organisé

1 · ALERT — machine Detected by the engine DOWN PARTIAL kept for the plan’s retention, even with no channel attached

2 · INCIDENT — human What you communicate severity · status · updates published on the status page created from an alert in one click

3 · ESCALADE Who, in what order 1 · now→ Slack 2 · +10 min→ PagerDuty 3 · +30 min→ Email until someone acknowledges

4 · CHANNELS Slack Email PagerDuty Webhook +14 more

Dashboard › Alerting: Alerts (history, acknowledge, CSV) · Incidents · Escalation · Channels · Maintenance One rule: a piece of information lives in one place. The bell in the top bar carries product notifications only, never monitoring alerts. The org status pill in the top bar and the “Alerts” badge in the sidebar are the permanent signals.

La section Alerting du dashboard s’articule autour de cinq objets, chacun avec sa page — et une règle : une information ne vit qu’à un seul endroit.

Page	Contenu
Alertes	Tout ce que le moteur a détecté — down, panne partielle, dégradé, rétabli, expiration SSL — notifié ou non.
Incidents	Ce que vous déclarez et communiquez : sévérité, statut, mises à jour, publication sur la page de statut.
Escalade	Qui est prévenu, dans quel ordre, après combien de temps sans acquittement.
Canaux	Les destinations : Slack, email, PagerDuty, webhooks… (dix-huit, voir ci-dessous).
Maintenance	Les fenêtres planifiées qui font taire les alertes des monitors concernés.

Une sixième page, Signalements visiteurs, rassemble ce que les visiteurs de vos pages de statut ont signalé eux-mêmes — voir Alertes depuis une page de statut.

La cloche de la barre du haut est une liste de choses à faire, pas un journal : elle montre ce qui demande votre attention maintenant — monitors en panne, incidents en cours, maintenance en cours — ainsi que les nouveaux signalements de visiteurs, et chaque entrée disparaît avec sa cause. Le signal permanent, c’est la pastille de statut dans la barre du haut et le badge Alertes de la sidebar ; l’historique, c’est le journal des alertes.

D’un check en échec à un humain prévenu

1. Détection — le check d’un agent échoue. Le moteur applique la fenêtre de retries et, pour les monitors multi-régions, la règle de majorité (voir Statut & uptime). Seul un changement d’état confirmé lève une alerte.
2. Alerte — une ligne dans le journal des alertes : quoi, quand, quel monitor, avec la preuve. L’acquitter là, c’est dire à OKStatus « quelqu’un s’en occupe ».
3. Notification — l’alerte est poussée vers chaque canal attaché au monitor, filtrée par les types d’alerte que chaque canal accepte. Ce qui a été envoyé, et si c’est arrivé, est stocké sur l’alerte.
4. Escalade — une politique d’escalade (une seule sur Free et Pro, sans limite sur Max et Enterprise) continue après le niveau 1 : d’autres canaux après N minutes sans acquittement, éventuellement en boucle, jusqu’à ce que quelqu’un acquitte.
5. Communication — vous décidez ce que voit l’extérieur : un incident sur la page de statut, une fenêtre de maintenance planifiée qui coupe les alertes avant des travaux prévus, et des emails aux abonnés qui partent tout seuls.

Qu’est-ce qui coupe quoi

Situation	Alerte levée ?	Canaux appelés ?	Page de statut
Monitor en pause	Non — aucun check ne tourne	Non	Affiché en pause
Monitor muet	Oui, journalisée	Non	Statut réel
Dans une fenêtre de maintenance	Non	Non	« En maintenance »
Alerte acquittée	Déjà levée	L’escalade s’arrête ; le rétablissement part quand même	Inchangée
Aucun canal attaché	Oui, avec le badge « aucun canal »	Rien à appeler	Inchangée