Comment surveiller les pages de statut des fournisseurs pour être alerté des pannes

Peu avant minuit, heure du Pacifique, le 19 octobre 2025, une situation de concurrence dans l'automatisation DNS d'Amazon DynamoDB a laissé le point de terminaison régional du service dans us-east-1 avec un enregistrement DNS vide. Tous les systèmes dépendant de DynamoDB dans cette région ont commencé à échouer, et l'impact s'est propagé aux autres services AWS qui en dépendaient. Selon le récapitulatif officiel d'AWS, l'incident a duré environ quatorze heures et demie.

Ce matin-là, de nombreuses équipes disposaient pourtant de serveurs en parfaite santé. Leurs sondes de disponibilité restaient au vert tandis que leur fournisseur d'authentification, leur passerelle de paiement ou leur service d'envoi d'e-mails étaient en difficulté. La plupart des pannes sont toutefois plus insidieuses : votre prestataire d'e-mails retarde les envois de quarante minutes, le support technique croule sous les tickets « mon lien de réinitialisation de mot de passe n'arrive pas », et quelqu'un finit par trouver la page de statut du fournisseur, qui affiche « Performances dégradées » depuis déjà une demi-heure.

Je travaille chez Page Deltas, un outil qui surveille les pages web publiques et vous alerte lorsqu'elles changent selon vos critères ; gardez cela à l'esprit lorsque je le compare à d'autres solutions ci-dessous. Cet article explique comment orienter la surveillance vers les pages de statut de vos prestataires essentiels : quelle URL choisir, comment rédiger un brief qui élimine le bruit inutile, où acheminer les alertes, et où s'arrêtent les limites de cette approche.

Pourquoi votre monitoring habituel reste au vert

Votre sonde de disponibilité (uptime) vérifie simplement si votre propre site répond, ce qui est généralement le cas pendant la panne d'un fournisseur tiers. Votre APM affichera un pic d'erreurs sur les appels sortants vers ce prestataire, mais ne pourra pas vous dire si le problème vient de votre code ou de leur infrastructure. C'est précisément la question à laquelle répond une page de statut, et la réponse change radicalement vos décisions : vous n'annulez pas le déploiement effectué une heure plus tôt ; vous informez le support qu'il s'agit d'un incident externe connu, et vous envisagez de mettre à jour votre propre page de statut.

Alors, pourquoi ne pas s'abonner directement sur la page du fournisseur ? Vous devriez le faire si cela répond à vos besoins. De nombreuses pages de statut s'appuient sur Atlassian Statuspage et proposent des alertes par e-mail, SMS, Slack, Teams ou webhooks, selon ce que le fournisseur a activé. Les complications surviennent au huitième prestataire : chaque abonnement nécessite une configuration séparée qui atterrit souvent dans la boîte de réception d'une seule personne, chaque fournisseur formate ses messages différemment, et filtrer uniquement les composants que vous utilisez n'est pas toujours possible. Certains prestataires gèrent même une page maison sans aucun bouton d'abonnement.

Un moniteur de changements web vous offre une méthode uniforme pour tous vos fournisseurs : vous collez l'URL de la page de statut, vous décrivez ce qui vous intéresse en une phrase, et chaque alerte arrive dans le même canal avec un format identique.

Quelles pages devez-vous surveiller ?

Choisissez la page qui affiche le statut en direct, généralement status.fournisseur.com. Évitez la page d'accueil générale ou la page marketing dédiée à la conformité. La plupart des pages de statut SaaS adoptent la même structure : une liste de composants avec un indicateur d'état, une bannière pour les incidents actifs, les maintenances planifiées à venir, et un historique court des incidents récents renvoyant vers l'historique complet.

Commencez par les dépendances dont vos clients ressentiraient l'impact immédiatement. Pour la plupart des équipes logicielles, la liste est courte.

Si vous ne pouvez en surveiller que quelques-unes, commencez par le haut de la liste. Les pannes de paiement et d'authentification se transforment en tickets de support en quelques minutes, tandis qu'un CDN ralenti ne sera parfois visible que dans vos métriques. Les 10 URL du forfait gratuit couvrent l'ensemble de ces cinq lignes tout en laissant de la marge pour les compléments ci-dessous.

Deux autres types de pages méritent votre attention. La page d'historique (souvent /history) constitue une excellente deuxième surveillance pour un fournisseur critique : un incident bref peut survenir et être résolu entre deux passages sur la page principale, mais il restera consigné dans l'historique, ce qui vous permettra d'en être informé a posteriori. Lors d'un incident prolongé, vous pouvez également ajouter l'URL de l'incident spécifique comme moniteur temporaire afin de recevoir chaque mise à jour. Supprimez-le une fois l'incident résolu, car chaque moniteur compte dans votre limite d'URL.

Mise en place

La configuration prend environ cinq minutes et suit le même principe que notre guide de surveillance des changelogs, avec un brief adapté.

1. Créez un compte et configurez un canal

Inscrivez-vous gratuitement, ouvrez Canaux, et ajoutez la destination souhaitée pour vos alertes. Je vous conseille de créer un canal dédié tel que #vendor-status plutôt que de poster dans #engineering, où les alertes risquent d'être noyées. Slack, Discord et Microsoft Teams acceptent une URL de webhook entrant. Dans Teams, faites un clic droit sur le canal, choisissez Connecteurs, puis Webhook entrant, puis Configurer, et collez l'URL dans Page Deltas. Pour l'e-mail, le destinataire doit préalablement valider un message de confirmation. Cliquez sur Envoyer un test sur chaque canal pour vous assurer de la bonne réception.

2. Ajoutez un moniteur avec un brief

Cliquez sur Nouveau moniteur et collez l'URL de la page de statut. Conservez un fournisseur par moniteur afin que chaque brief puisse nommer précisément les composants concernés, et si différentes équipes s'intéressent à des prestataires distincts, associez un canal différent à chaque moniteur.

Les pages de statut évoluent plus souvent qu'on ne l'imagine, même lors d'une journée calme : les pourcentages de disponibilité fluctuent, les horodatages « dernière mise à jour » avancent, et la liste des incidents récents décale d'un jour avec une nouvelle ligne « Aucun incident signalé ». Les maintenances planifiées sont quant à elles annoncées des semaines à l'avance. Un outil de diff classique se déclencherait sur chacun de ces détails.

La description du moniteur constitue le prompt que notre LLM analyse pour décider si un changement mérite une alerte. Rédigez-la comme une consigne transmise à un collègue qui surveillerait la page pour vous. Pour un fournisseur d'e-mails, voici un exemple très efficace :

Page de statut de notre fournisseur d'e-mails. Nous utilisons uniquement
les composants Email API et Webhooks, dans la région US.
Alertez-moi lorsqu'un nouvel incident est publié qui affecte ces composants
ou cette région, lorsque son statut ou sa gravité change, ou lorsqu'il est
résolu. Alertez-moi si l'un de ces composants quitte l'état Operational.
Ignorez les pourcentages de disponibilité, les horodatages « dernière mise à jour »,
les lignes quotidiennes « Aucun incident signalé » et les incidents dans d'autres régions.
Ne mentionnez la maintenance planifiée que si elle débute dans les 48 heures.
Résumez le composant affecté, le statut actuel et la dernière mise à jour.

La consigne d'exclusion accomplit l'essentiel du travail. Si vous l'omettez, vous passerez votre première semaine à recevoir des alertes dues au simple basculement de la liste des incidents à minuit.

Pour un grand fournisseur de cloud, préciser les régions et les services est encore plus capital. Un tableau de bord cloud public répertorie des centaines de services à travers des dizaines de régions, et lors d'une semaine normale, il y a toujours un composant dégradé quelque part. Nommez explicitement les régions et les services sur lesquels repose votre infrastructure, et demandez à n'être alerté que pour ceux-ci.

3. Laissez la première vérification établir la référence

Un nouveau moniteur effectue sa première vérification peu après sa création. Cette vérification enregistre l'état initial, vous ne recevrez donc aucune fausse alerte à la première minute à moins que la page ne change entre deux passages. Consultez ensuite le moniteur et vérifiez la capture d'écran pour confirmer qu'elle englobe bien la liste des composants attendus.

4. Déclenchez une vérification manuelle en cas de doute

Vous ne définissez pas d'intervalle rigide dans Page Deltas. La planification est adaptative : les pages qui bougent souvent sont vérifiées plus fréquemment, et les forfaits payants bénéficient d'une priorité en cas d'affluence. Une page de statut restant calme la plupart du temps, si votre taux d'erreurs grimpe et que vous soupçonnez un fournisseur, cliquez sur Vérifier maintenant sur son moniteur. La même action est disponible via l'API, avec une limite d'une fois par minute et par moniteur :

curl -X POST \
  -H "Authorization: Bearer $PAGEDELTAS_TOKEN" \
  https://api.pagedeltas.com/api/monitors/$MONITOR_ID/check-now

Que faire lorsqu'une alerte arrive

Lorsqu'un changement correspond à votre brief, vous recevez un message unique comprenant un résumé en langage clair ainsi que les captures d'écran avant et après. Si vous utilisez le webhook signé, la charge utile ressemble à ceci (les valeurs sont fictives pour l'exemple) :

{
  "event": "change.detected",
  "monitor_id": "01HX7Q...",
  "monitor_url": "https://status.example-mail.com/",
  "monitor_name": "Statut du fournisseur d'e-mails",
  "change_id": "...",
  "detected_at": "2026-10-14T07:21:00Z",
  "summary": "Nouvel incident : ralentissement des envois d'e-mails dans la région US. Email API est passé de Operational à Degraded Performance. Statut : En cours d'analyse.",
  "before_screenshot_url": "https://.../before.png",
  "after_screenshot_url": "https://.../after.png",
  "dashboard_url": "https://app.pagedeltas.com/monitors/..."
}

La première personne qui prend connaissance de l'alerte devrait répondre dans le fil pour expliquer les répercussions concrètes. Le support peut épingler une réponse d'incident connu avant que les tickets ne s'accumulent. L'ingénieur d'astreinte peut cesser d'éplucher un déploiement qui n'est pas responsable des erreurs, et si la panne affecte directement les utilisateurs, mettez à jour votre propre page de statut pour que vos clients l'apprennent d'abord par vous.

Si votre équipe utilise PagerDuty ou un autre outil de gestion d'incidents, le webhook signé permet d'alimenter ces outils via un petit relais. Notre charge utile n'étant pas au format natif de PagerDuty, quelques lignes de code dans une fonction serverless suffisent pour vérifier la signature et relayer l'événement :

import crypto from "node:crypto";

export async function handle(rawBody, signature) {
  const expected = "sha256=" + crypto
    .createHmac("sha256", process.env.PAGEDELTAS_WEBHOOK_SECRET)
    .update(rawBody).digest("hex");
  if (signature.length !== expected.length ||
      !crypto.timingSafeEqual(Buffer.from(signature), Buffer.from(expected))) {
    return 401;
  }
  const alert = JSON.parse(rawBody);
  await fetch("https://events.pagerduty.com/v2/enqueue", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      routing_key: process.env.PAGERDUTY_ROUTING_KEY,
      event_action: "trigger",
      dedup_key: alert.change_id,
      payload: { summary: alert.summary, source: alert.monitor_url, severity: "warning" },
      links: [{ href: alert.dashboard_url, text: "Open in Page Deltas" }],
    }),
  });
  return 200;
}

Calculez l'empreinte cryptographique sur le corps brut avant de le parser en JSON, sinon la signature ne correspondra pas. La documentation sur les canaux détaille le protocole. Chaque alerte est envoyée une seule fois par canal sans nouvelle tentative automatique : pour vos prestataires les plus critiques, associez un deuxième canal de type différent (Slack combiné à l'e-mail, par exemple) en cas de défaillance passagère de Slack ou du relais.

Les limites à connaître

Cette configuration vous informe de ce qu'un fournisseur déclare publiquement, ce qui implique plusieurs limites essentielles à garder en tête avant de vous y fier aveuglément.

Les prestataires tardent souvent à publier leurs incidents. Vos propres graphiques d'erreurs afficheront parfois des anomalies bien avant que la page de statut n'admette quoi que ce soit : considérez donc cette alerte comme une confirmation plutôt que comme votre premier signal d'alarme. De plus, cela ne remplace en aucun cas les tests synthétiques ou le monitoring de disponibilité de votre propre API. Ces derniers vous indiquent que votre produit est défaillant ; la page de statut vous explique pourquoi.

Entre deux vérifications, un changement est détecté lors du prochain passage planifié, sans intervalle fixe garanti. Pour les un ou deux fournisseurs où chaque minute compte, conservez également l'abonnement natif du prestataire et utilisez Page Deltas pour tout le reste. Enfin, nous ne surveillons que les pages publiques : un statut visible uniquement à l'intérieur d'une console d'administration reste hors de portée pour l'instant.

Nous comparons le texte de chaque page. Si un fournisseur indique son statut uniquement au moyen d'un voyant coloré sans aucune variation textuelle, nous ne pourrons pas le détecter. Visualping permet de surveiller une zone de pixels précise et convient mieux à ce cas particulier. Enfin, si la page de statut elle-même tombe en panne, les vérifications échouent au lieu d'alerter, et après 10 échecs consécutifs, le moniteur se met en pause automatique et vos administrateurs sont notifiés.

Commencez par trois fournisseurs

Identifiez les trois prestataires dont l'interruption vous pénaliserait le plus — généralement le paiement, l'authentification et l'e-mail. Collez les URL de leurs pages de statut, adaptez le brief ci-dessus avec vos composants et régions respectifs, et envoyez une alerte de test dans #vendor-status. Le forfait gratuit inclut 10 URL avec filtrage IA, tous les canaux d'alerte et l'accès API, sans nécessiter de carte bancaire. Commencer la surveillance gratuitement.

Julien, chef de produit chez Page Deltas