Aller au contenu

Canaux d'alerte

Page Alerting → Canaux : nombre de canaux, santé des envois, couverture des monitors et dernier envoi, puis vos canaux regroupés par type

OKStatus supporte dix-neuf canaux de notification. Chaque canal est un objet au niveau de l’organisation, associé aux monitors qui doivent le notifier. La case Appliquer à tous mes monitors de la fenêtre de création est cochée par défaut : un nouveau canal démarre donc attaché à tous les monitors que vous avez à cet instant — décochez-la pour choisir vous-même. Les monitors créés plus tard ne sont jamais attachés automatiquement.

CanalPlan
DiscordFree
WebhookFree
TelegramFree
EmailPro
SlackPro
Google ChatPro
AlertmanagerPro
PushoverPro
Rocket.ChatPro
MattermostPro
SMSPro (crédits)
ntfyMax
Microsoft TeamsMax
Splunk (HEC)Max
PagerDutyMax
Grafana IRMMax
Jira Service ManagementMax
incident.ioMax
JiraEnterprise

Chaque palier inclut tous les canaux des paliers inférieurs. Le plan est vérifié à la création d’un canal — un canal créé avant un changement continue de fonctionner.

La configuration des canaux basés sur un webhook est détaillée sur leurs propres pages : Discord, Webhooks, Alertmanager, Pushover, Rocket.Chat, Mattermost, Grafana IRM, Jira Service Management, incident.io et Jira. Slack, Telegram, ntfy, MS Teams, Splunk, Google Chat et PagerDuty sont couverts par Autres canaux.

Les quatre tuiles en haut de la page résument l’ensemble : combien de canaux sont actifs, combien ne délivrent plus (voir Livraison — webhook expiré, jeton révoqué), combien de monitors ont au moins un canal (Couverture, avec un lien vers ceux qui n’en ont aucun), et de quand date la dernière notification.

Le canal le plus simple. Chaque changement d’état (UP → DOWN, DOWN → UP) génère un email.

Configuration :

  1. Allez dans Alerting → Canaux (ou associez-en un directement depuis la dernière étape de l’assistant de création de monitor).
  2. Cliquez sur « Ajouter un canal » → Email.
  3. Saisissez l’adresse de réception.
  4. Cliquez sur « Créer ».

L’email de notification contient le nom du monitor et son URL, le nouveau statut, la région qui a détecté le problème, et l’heure exacte du changement d’état.

Fenêtre Vérifier ce numéro : un code à 6 chiffres a été envoyé au numéro du canal, un champ pour le saisir et un bouton Vérifier

Des SMS sur un téléphone, pour les alertes qui doivent réveiller quelqu’un. Seules les alertes de panne et de rétablissement partent par SMS ; les états dégradé et en pause, non. Chaque SMS consomme des crédits prépayés — voir Crédits SMS.

Mise en place :

  1. Allez dans Alerting → Canaux et cliquez sur SMS (à partir du plan Pro).
  2. Saisissez le numéro de mobile au format international, avec l’indicatif du pays : +33 6 12 34 56 78.
  3. Cliquez sur Créer le canal. La fenêtre envoie alors un code à 6 chiffres à ce numéro.
  4. Saisissez le code et cliquez sur Vérifier.

Tant que le numéro n’est pas vérifié, le canal n’envoie rien : sa ligne affiche Numéro non vérifié avec un lien Vérifier le numéro. Le code est gratuit, valable 10 minutes, avec 5 essais ; un numéro modifié plus tard doit être revérifié. Cette étape garantit que personne ne peut diriger des alertes vers le téléphone de quelqu’un qui n’a pas accepté de les recevoir.

Pays : numéros européens uniquement — Union européenne, Islande, Liechtenstein, Norvège, Royaume-Uni et Suisse. Un SMS coûte 1 crédit vers la France, l’Espagne, l’Italie, le Royaume-Uni, le Portugal ou la Pologne, 2 vers la Belgique, l’Autriche, les Pays-Bas ou les pays nordiques, et 3 vers l’Allemagne.

Plafonds : pour qu’une tempête d’alertes ne vide pas vos crédits, une organisation envoie au plus 10 SMS par heure et 40 par jour, et un même numéro en reçoit au plus 5 par heure. Au-delà, les alertes continuent par vos autres canaux, et la liste Derniers SMS de la page Facturation montre celles qui ont été retenues.

Le message ressemble à OKStatus: checkout-api is DOWN (Paris). https://api.example.com — 160 caractères au plus, donc une alerte = un SMS. Les SMS partent par OVHcloud, depuis la France.

Quand un fournisseur refuse une alerte, OKStatus regarde pourquoi :

  • Erreurs passagères — délai dépassé, erreur réseau, 5xx ou 429 (limite d’envoi). OKStatus réessaie ce canal après 30 s, puis 2 min, puis 10 min. La ligne de la page Canaux affiche Nouvelle tentative dans… pendant ce temps. Une relance est abandonnée si l’état du monitor a changé (une DOWN n’arrive jamais après la UP qui l’a terminée), si l’alerte a été acquittée ou si le canal a été désactivé.
  • Erreurs définitives — redirection (301/302, le plus souvent une URL de webhook tronquée ou supprimée), 401/403 (jeton révoqué), 404/410 (intégration supprimée), 405, 400/422. Réessayer échouerait de la même façon : OKStatus ne relance pas. La ligne du canal explique en clair ce qui ne va pas, avec Modifier à côté.

Un canal est en échec après 3 échecs définitifs d’affilée (un délai dépassé relancé trois fois compte pour un), ou après 24 heures d’échecs sans aucun envoi réussi. Le propriétaire et les admins de l’organisation reçoivent alors un e-mail, dans la langue de l’organisation, avec le canal, la réponse du fournisseur et les monitors concernés. Rien d’autre n’est envoyé tant que le canal ne délivre pas à nouveau : la première alerte livrée ou un Test réussi le ré-arme. Les autres canaux des monitors continuent de recevoir les alertes entre-temps.

Un canal ne s’applique pas à tous les monitors du simple fait d’exister. Vous le configurez soit :

  • À la création du monitor — la dernière étape de l’assistant « Nouveau monitor » permet de sélectionner des canaux existants (ou d’en créer un) directement.
  • Depuis la page de détail du monitor — associez, dissociez ou ajustez les types d’alerte d’un canal à tout moment.
  • Depuis Alerting → Canaux — le menu du canal (⋮) permet de lui attacher des monitors, de l’appliquer à tous les monitors, ou à tous les monitors portant un tag donné, en une seule action.

Pour chaque canal associé à un monitor, vous pouvez activer ou désactiver indépendamment les types d’événements qu’il doit notifier :

  • Up / down — l’état de disponibilité du monitor change.
  • Expiration du certificat SSL — le certificat TLS du monitor approche de son expiration.
  • Expiration du domaine — l’enregistrement du domaine surveillé approche de son expiration.

Les trois sont activés par défaut. Décochez-en si, par exemple, vous voulez que votre canal Discord n’alerte que sur les pannes tandis que l’email porte aussi les avertissements d’expiration de certificat.

1 · CHECK Region fails retries + 1 in a row 2 · MONITOR STATUS Majority rule 1 region → partial · >½ → down all healthy → recovered 3 · ONE EVENT PER TRANSITION PARTIAL OUTAGE DOWN RECOVERED not re-sent while it lasts lists the failing regions with total downtime 4 · CHANNELS ATTACHED TO THE MONITOR Email Slack Discord PagerDuty Webhook Telegram +12 more Each channel picks the kinds it wants: up/down · SSL expiry · domain expiry. Muted monitors and maintenance windows send nothing.

Un check échoué isolé ne vous réveille jamais. Deux garde-fous s’appliquent, pilotés par les réglages du monitor :

  1. Fenêtre de retries — une région ne confirme une panne qu’après retries + 1 échecs consécutifs (défaut : 2). Le premier échec s’affiche degraded ; pour un monitor mono-région il envoie aussi un avertissement léger.
  2. Règle de majorité — un monitor multi-région n’est down que lorsque plus de la moitié de ses régions confirment la panne. Une seule région = panne partielle : statut orange et une alerte qui nomme cette région — vous savez que quelque chose cloche depuis ce point de vue, sans faux « tout est down ».

Le rétablissement est annoncé une fois, quand toutes les régions sont de nouveau saines. Chaque type d’alerte part une seule fois par transition, jamais répété tant que l’état dure. Règles complètes et schémas : Statut & uptime.

Pour chaque monitor, vous pouvez également configurer :

OptionDescriptionDéfaut
Nouveaux essaisÉchecs consécutifs tolérés avant que le monitor soit marqué down1
MuteSilencer les alertes d’un monitor sans mettre en pause ses checksDésactivé
  • Combinez email + Discord/Slack — email pour l’archive, chat pour la réactivité.
  • Utilisez les webhooks pour alimenter votre outil d’astreinte (PagerDuty, Opsgenie).
  • Passez un monitor en mute pendant une période bruyante connue plutôt que de le désactiver entièrement — les checks continuent, seules les alertes se taisent.
  • Testez vos canaux après configuration avec le bouton Tester à côté de chacun.
  • Surveillez les lignes « aucun canal » de la page Alertes — une alerte détectée mais jamais envoyée est l’oubli le plus courant après l’ajout de monitors.