Personne ne planifie une panne.

Ericsson a confirmé le jour même qu’un certificat expiré dans 2 versions logicielles de ses nœuds de cœur de réseau SGSN-MME avait causé la panne. SoftBank a indiqué que le logiciel tournait depuis 9 mois. Le rétablissement a consisté à revenir à l’ancienne version.

Ce que montre un check depuis l’extérieur Le certificat se trouvait dans le logiciel du fournisseur, un check de certificat TLS ne l’aurait donc pas vu. Des sondes externes ne mesurent pas non plus le chemin des données mobiles. Une page de statut porte le message aux clients, et le registre de disponibilité donne une base aux crédits.

• Check de certificat TLS

Source : Communiqué de presse Ericsson, 2018-12-06 · Communiqué de presse SoftBank, 2018-12-06 · MoneySavingExpert, 2018-12-07

Microsoft 365 Status a écrit qu’un certificat d’authentification avait expiré et qu’un correctif appliquerait un nouveau certificat. Les utilisateurs ne pouvaient plus se connecter.

Ce que montre un check depuis l’extérieur Microsoft n’a pas précisé si ce certificat se trouvait sur un endpoint public. Impossible donc de savoir si un check de certificat l’aurait détecté. Un check HTTP du parcours de connexion depuis plusieurs régions peut montrer la défaillance après 2 checks consécutifs en échec, quel que soit l’emplacement du certificat. Une page de statut répond à la première question de vos clients : le problème vient-il de chez nous ou de Teams ?

• Check HTTP(S)
• Check de certificat TLS

{
  "name": "Sign-in page",
  "type": "http",
  "interval_seconds": 60,
  "config": { "url": "https://app.example.com/login", "expected_status": 200 }
}

Source : TechCrunch, 2020-02-03, citant Microsoft 365 Status

Le rapport d’incident de Google cite un problème de mise à jour des configurations de certificats, qui a laissé expirer le certificat actif des frontaux de Google Voice.

Ce que montre un check depuis l’extérieur Un check de certificat TLS sur l’endpoint public signale la durée de vie restante des jours à l’avance, depuis un système extérieur à la rotation qui a échoué. La rotation elle-même reste l’affaire de l’exploitant.

• Check de certificat TLS

{
  "name": "Voice front-end certificate",
  "type": "ssl_cert",
  "interval_seconds": 900,
  "config": { "host": "voice.example.com", "port": 443, "warn_days": 21 }
}

Source : Rapport d’incident Google Workspace (PDF) · BleepingComputer, 2021-02-28

Le Government Accountability Office des États-Unis a établi qu’un certificat de l’équipement chargé d’inspecter le trafic réseau chiffré avait expiré environ 10 mois avant le début de l’intrusion. Jusqu’à son renouvellement, le trafic n’a pas été inspecté.

Ce que montre un check depuis l’extérieur L’équipement n’était pas un endpoint public, un check de certificat ne l’aurait donc pas vu. Le cas figure ici pour une seule raison : il montre qu’un certificat expiré peut passer inaperçu pendant des mois quand personne ne surveille les dates d’expiration. La réponse minimale est un inventaire de tous vos certificats, avec un check depuis l’extérieur pour les certificats publics.

• Check de certificat TLS

Source : GAO-18-559, 2018-08-30

Pendant une maintenance, une commande destinée à évaluer la capacité du backbone a coupé toutes ses connexions, et un outil d’audit n’a pas su l’arrêter. Les serveurs DNS faisant autorité de Meta retirent leurs annonces BGP quand ils ne joignent plus les centres de données. Ils ont donc disparu d’Internet tout en continuant de tourner. Les outils internes de diagnostic sont partis avec eux, et les ingénieurs ont dû entrer en personne dans les centres de données.

Ce que montre un check depuis l’extérieur Après 2 checks consécutifs en échec, des checks DNS depuis plusieurs régions signalent que le domaine ne se résout plus nulle part, et des checks traceroute montrent que les routes ont disparu. Meta a perdu ses propres outils avec son réseau, et une vue depuis l’extérieur continue de fonctionner précisément dans cette situation. Une page de statut doit vivre sur un autre domaine, ou au moins chez un autre opérateur DNS, sinon elle disparaît aussi.

• Check d’enregistrement DNS
• Check traceroute

{
  "name": "Apex A record",
  "type": "dns",
  "interval_seconds": 60,
  "config": { "name": "example.com", "record_type": "A" }
}

Source : Meta Engineering, 2021-10-05 · Cloudflare, 2021-10-04

Un ingénieur a utilisé la procédure de correction d’urgence pour un déploiement DNS mondial au lieu de la procédure par étapes. Sous la charge, un script vieux de 4 ans a dépassé son délai d’attente, les serveurs DNS ne sont pas revenus après redémarrage, et les outils de rétablissement dépendaient d’eux. La page de statut n’était joignable que par intermittence, ce que Salesforce a attribué à l’absence d’auto-scaling sur la page, pas au DNS.

Ce que montre un check depuis l’extérieur Des checks DNS depuis plusieurs régions signalent la perte de résolution après 2 checks consécutifs en échec. Plus important, une page de statut sert précisément quand tout le monde regarde en même temps. Elle doit donc tourner hors de votre propre plateforme et tenir le trafic d’un incident. C’est une propriété d’une page de statut hébergée à part, pas un mérite du check lui-même.

• Check d’enregistrement DNS
• Check HTTP(S)

{
  "name": "App host record",
  "type": "dns",
  "interval_seconds": 60,
  "config": { "name": "app.example.com", "record_type": "A" }
}

Source : The Register, 2021-05-12 · The Register, 2021-05-19

La gestion DNS de DynamoDB repose sur un planificateur et plusieurs exécuteurs. Un exécuteur appliquait un ancien plan pendant qu’un second en appliquait un plus récent, puis supprimait l’ancien plan à son étape de nettoyage. AWS a écrit qu’au moment où ce plan a été supprimé, toutes les adresses IP de l’endpoint régional ont été retirées immédiatement. Les effets en cascade sur EC2 et les répartiteurs de charge ont prolongé le rétablissement jusque dans l’après-midi.

Ce que montre un check depuis l’extérieur Des checks DNS et HTTP de vos propres endpoints depuis plusieurs régions signalent la panne après 2 checks consécutifs en échec et montrent si votre région est touchée. La page de statut a sa place hors de la région et de la plateforme qui font tourner vos services. Le registre de disponibilité vous donne votre propre série temporelle pour les questions des clients et pour une demande de crédit de service, où c’est à vous de prouver l’indisponibilité.

• Check d’enregistrement DNS
• Check HTTP(S)

{
  "name": "API endpoint record",
  "type": "dns",
  "interval_seconds": 60,
  "config": { "name": "api.example.com", "record_type": "A" }
}

Source : Résumé post-événement AWS, octobre 2025

Akamai a indiqué qu’une mise à jour de configuration logicielle à 15:45 UTC avait déclenché un bug dans le système DNS, et a exclu une attaque.

Ce que montre un check depuis l’extérieur Un check DNS depuis plusieurs régions montre que votre propre zone ne se résout plus, sans attendre la déclaration du fournisseur. La page de statut ne doit pas dépendre du même DNS.

• Check d’enregistrement DNS

{
  "name": "Zone name servers",
  "type": "dns",
  "interval_seconds": 60,
  "config": { "name": "example.com", "record_type": "NS" }
}

Source : Akamai, 2021-07-22

Pendant une procédure standard, un ingénieur habilité a saisi un paramètre incorrect et retiré plus de serveurs que prévu. Parmi eux figurait une partie de la capacité des sous-systèmes d’index et de placement de S3, et les deux sous-systèmes ont dû être redémarrés entièrement. AWS a écrit que jusqu’à 11:37 PST, il ne pouvait pas actualiser l’état de chaque service sur le tableau de bord, dont la console dépendait de S3. AWS a communiqué par Twitter et une bannière pendant 2 heures, puis a réparti l’administration du tableau de bord entre plusieurs régions.

Ce que montre un check depuis l’extérieur Le cas illustre une règle : ne jamais héberger la page de statut sur l’infrastructure dont elle affiche l’état. Perstat sert votre page de statut depuis sa propre infrastructure, pas depuis la plateforme surveillée. Des checks HTTP depuis plusieurs régions auraient signalé les endpoints S3 comme défaillants après 2 checks consécutifs en échec. AWS le savait déjà, le gain tient donc entièrement à une communication indépendante.

• Check HTTP(S)

{
  "name": "Asset storage",
  "type": "http",
  "interval_seconds": 60,
  "config": { "url": "https://assets.example.com/health", "expected_status": 200 }
}

Source : Post-mortem AWS, mars 2017

Après un changement de permissions sur un cluster ClickHouse, une requête a renvoyé des métadonnées de colonnes en double. Le fichier de features de la gestion des bots a doublé de taille et dépassé une limite dure de 200 features dans le proxy. Le processus a échoué sur un panic Rust. La page de statut, hébergée indépendamment, est tombée au même moment pour une raison sans rapport. L’équipe a donc d’abord soupçonné une attaque coordonnée.

Ce que montre un check depuis l’extérieur Si vous utilisez Cloudflare, des checks HTTP depuis plusieurs régions avec quorum signalent partout des réponses 5xx de votre site après 2 checks consécutifs en échec. Vous savez ainsi si le problème vient de chez vous ou du fournisseur. Votre propre page de statut sur une infrastructure indépendante sert vos clients pendant que le tableau de bord et la page de statut du fournisseur sont indisponibles. Seul Cloudflare pouvait réparer quoi que ce soit.

• Check HTTP(S)

{
  "name": "Website behind the CDN",
  "type": "http",
  "interval_seconds": 60,
  "config": { "url": "https://www.example.com/", "expected_status": 200 }
}

Source : Blog Cloudflare, 2025-11-18

Le 29 mai, une fonctionnalité de contrôles de politique de quota supplémentaires est arrivée dans Service Control sans feature flag et sans gestion d’erreur sur le nouveau chemin. Le 12 juin, un changement de politique a produit des champs vides, et les binaires ont planté dans le monde entier sur une erreur de pointeur nul. Google a écrit que son premier rapport d’incident était paru environ une heure après le début des plantages, parce que l’infrastructure de Cloud Service Health était elle-même tombée. Google a aussi écrit que, pour certains clients, l’infrastructure de monitoring qu’ils faisaient tourner sur Google Cloud tombait également, ce qui les laissait sans signal de l’incident.

Ce que montre un check depuis l’extérieur Cette dernière phrase plaide pour le monitoring externe, dans les mots de l’exploitant lui-même : un monitoring sur la même plateforme tombe avec elle. Perstat vérifie depuis l’extérieur, depuis 6 régions au plus, avec quorum, et son infrastructure de sondes ne tourne pas sur la plateforme qu’elle surveille. Une page de statut sur une infrastructure séparée aurait informé vos clients pendant cette heure.

• Check HTTP(S)
• Check d’enregistrement DNS

{
  "name": "Public API",
  "type": "http",
  "interval_seconds": 60,
  "config": { "url": "https://api.example.com/health", "expected_status": 200 }
}

Source : Rapport d’incident Google Cloud, 2025-06-12 · The Register, 2025-06-16

Un script destiné à supprimer les instances d’une app retirée a reçu des identifiants de sites au lieu d’identifiants d’apps. Il a supprimé des sites clients entiers pendant 23 minutes, à partir de 07:38 UTC. Le premier ticket client est arrivé à 07:46 UTC, au bout de 8 minutes, et le processus d’incident majeur a démarré à 08:17 UTC. La première mise à jour de la page de statut est venue à 09:03 UTC, au bout de 85 minutes, et la première déclaration externe large sur les réseaux sociaux le 7 avril, au bout de 41 heures. La restauration a pris jusqu’à 14 jours et n’était que partiellement automatisée.

Ce que montre un check depuis l’extérieur Un check HTTP de votre propre URL de tenant depuis plusieurs régions signale la panne après 2 checks consécutifs en échec, sans attendre un ticket de support. Certains clients ont perdu Statuspage et Opsgenie avec leurs sites. La page de statut et l’alerte ne doivent donc pas se trouver chez le fournisseur dont elles sont censées montrer la panne. Aucun monitoring n’aurait raccourci les 14 jours.

• Check HTTP(S)

{
  "name": "Tenant site",
  "type": "http",
  "interval_seconds": 60,
  "config": { "url": "https://yourteam.example.com/", "expected_status": 200 }
}

Source : Revue post-incident Atlassian, 2022-04-29

Le PDG a écrit que l’entreprise renouvelle chaque année des milliers de domaines avec précision, mais que le processus de renouvellement automatique de son domaine principal avait échoué. La déclaration citait une erreur humaine et de processus comme cause. Les clients se sont plaints publiquement sur Twitter.

Ce que montre un check depuis l’extérieur Un check de domaine signale la date d’expiration des jours à l’avance, depuis un système qui ne dépend pas du renouvellement automatique défaillant. Un check DNS depuis plusieurs régions aurait signalé la perte de résolution après 2 checks consécutifs en échec. Une page de statut sur un autre domaine aurait porté le message pendant que marketo.com ne se résolvait plus, mais aucun check ne peut renouveler le domaine.

• Check de domaine
• Check d’enregistrement DNS

{
  "name": "Company domain",
  "type": "domain",
  "interval_seconds": 300,
  "config": { "domain": "example.com", "warn_days": 30 }
}

Source : Base de connaissances Marketo (Adobe), P1 du 25 juillet 2017 · The Drum, 2017-07-26

L’impact sur les utilisateurs en 2003 n’est pas documenté. Ce cas compte donc comme une perte de contrôle, pas comme une panne.

Ce que montre un check depuis l’extérieur Un check de domaine avec avertissement d’expiration sur chaque domaine que vous possédez, y compris ceux auxquels personne ne pense.

• Check de domaine

{
  "name": "Secondary domain",
  "type": "domain",
  "interval_seconds": 300,
  "config": { "domain": "example.co.uk", "warn_days": 30 }
}

Source : Slashdot, 1999-12-25 · The Register, 2003-11-06

En réparant la réplication, un ingénieur a supprimé le répertoire de données sur le primaire au lieu du secondaire. Les sauvegardes pg_dump n’existaient pas, parce que le script lançait pg_dump 9.2 contre PostgreSQL 9.6 et échouait. GitLab a écrit que les notifications des jobs cron en échec partaient par e-mail, mais que DMARC n’était pas activé pour ces e-mails, si bien que le destinataire les rejetait. Les instantanés de disque n’étaient pas activés pour les serveurs de base de données, et il ne restait qu’un instantané LVM manuel, vieux de 6 heures.

Ce que montre un heartbeat Un heartbeat fonctionne comme un dead man’s switch : le job de sauvegarde se signale après un succès, et Perstat alerte si le signal manque, qu’un e-mail d’erreur arrive ou non. Le cas montre aussi que l’alerte ne doit pas dépendre d’un seul canal susceptible de tomber lui-même. L’escalade doit donc passer par plusieurs voies et exiger un acquittement. Un heartbeat ne vérifie pas si la sauvegarde peut être restaurée. Cela reste le rôle d’un test de restauration.

• Check heartbeat

{
  "name": "Nightly database backup",
  "type": "heartbeat",
  "config": { "period_seconds": 86400, "grace_seconds": 1800 }
}

Source : Post-mortem GitLab, 2017-02-10 · The Register, 2017-02-01, sur les 5 techniques de sauvegarde

Un incendie dans la nuit du 10 mars 2021 a détruit le centre de données SBG2 à Strasbourg et une partie de SBG1, et SBG1 à SBG4 sont passés hors ligne. Dans 2 jugements de 2023, le tribunal a estimé que la séparation physique des sauvegardes promise par contrat n’était pas assurée. OVHcloud a fait appel du premier jugement et, selon Blocks and Files, entendait faire appel du second.

Ce que montre un heartbeat Un heartbeat prouve qu’un job de sauvegarde a tourné, pas où se trouve la copie ni si elle peut être restaurée sur un autre site. Des checks HTTP depuis plusieurs régions auraient signalé la panne après 2 checks consécutifs en échec. Une page de statut hébergée chez un autre fournisseur aurait atteint les clients.

• Check heartbeat
• Check HTTP(S)

{
  "name": "Off-site backup copy",
  "type": "heartbeat",
  "config": { "period_seconds": 86400, "grace_seconds": 1800 }
}

Source : Netcraft, 2021-03-09 · Blocks and Files, 2023-03-23

La fonction informatique centrale a mis à jour le logiciel du traitement nocturne des comptes, a constaté des problèmes et a désinstallé la mise à jour sans en tester les conséquences. Les versions étaient incompatibles, le traitement par lots s’est bloqué et les écritures se sont accumulées pendant des semaines. La FCA a retenu l’absence de systèmes et de contrôles adéquats pour identifier et gérer le risque informatique.

Ce que montre un heartbeat Un heartbeat par exécution du traitement signale la clôture nocturne manquante dès la nuit même. Des checks HTTP sur les portails clients donnent la vue depuis l’extérieur, et le registre de disponibilité donne au régulateur une série temporelle au lieu d’estimations. Aucun monitoring n’aurait changé le retour arrière défectueux ni les semaines de nettoyage. Le montant de l’amende montre ce qu’un régulateur entend par contrôles manquants.

• Check heartbeat
• Check HTTP(S)

{
  "name": "Nightly batch close",
  "type": "heartbeat",
  "config": { "period_seconds": 86400, "grace_seconds": 3600 }
}

Source : Financial Conduct Authority, 2014-11-20

Le nouveau code a été déployé sur 7 des 8 serveurs. Le huitième a gardé l’ancien code, qui a réactivé une fonction inutilisée depuis 2003. Avant l’ouverture, un système interne a envoyé à un groupe de collaborateurs 97 e-mails mentionnant l’erreur du routeur, et selon la SEC, personne n’y a donné suite.

Ce que montre un check depuis l’extérieur Ce n’était pas une panne de disponibilité, mais le cas plaide pour une alerte qui exige un acquittement. Perstat n’aurait pas détecté le défaut logiciel, le cas figure donc ici pour la seule logique d’alerte.

Source : U.S. Securities and Exchange Commission, 2013-10-16

La BaFin a cité des pannes de la banque en ligne et mobile et un service client difficilement joignable par téléphone. Elle a aussi cité de longs délais de traitement pour les saisies et les successions, les clôtures de comptes et les remboursements d’épargne. Elle a enfin relevé des altérations significatives pour les comptes protégés contre les saisies. Le commissaire devait veiller à la levée rapide et complète des restrictions et faire rapport régulièrement.

Ce que montre un check depuis l’extérieur Des checks HTTP depuis plusieurs régions enregistrent la part mesurable depuis l’extérieur : les pannes de la banque en ligne et mobile. Un registre de disponibilité qui indique ses bornes donne aux régulateurs et aux clients des chiffres au lieu d’assurances. La plus grande part, arriérés de traitement et service téléphonique, ne relève pas du monitoring. Qui affirme une disponibilité devrait pouvoir la prouver avant que le régulateur ne pose la question.

• Check HTTP(S)

{
  "name": "Online banking login",
  "type": "http",
  "interval_seconds": 60,
  "config": { "url": "https://banking.example.com/login", "expected_status": 200 }
}

Source : BaFin, 2023-09-04 · BaFin, 2023-10-02 · heise online, 2023-10-02 · onvista (Reuters), 2023-07-03, sur les chiffres de la migration

L’administration fiscale bavaroise a parlé d’une demande très élevée et a exclu une attaque. L’interface pour les logiciels fiscaux a continué de fonctionner.

Ce que montre un check depuis l’extérieur Des checks HTTP avec temps de réponse depuis plusieurs régions montrent la dégradation avant la panne et laissent la série temporelle. Une page de statut avec un avis réduit le nombre de tentatives de rechargement. C’était un problème de capacité connu de l’exploitant, pas un problème de détection. Le cas figure donc ici comme exemple, dans le secteur public, de l’ampleur d’une panne et du besoin de communiquer.

• Check HTTP(S)

{
  "name": "Tax portal",
  "type": "http",
  "interval_seconds": 60,
  "config": { "url": "https://portal.example.com/", "expected_status": 200 }
}

Source : heise online, 2022-07-11 · Haufe, 2022-07-13

Selon le rapport de situation 2017 du BSI, une attaque mondiale d’une variante de Mirai sur le port 7547 a fait planter les routeurs de Telekom. Les routeurs n’ont pas été infectés, mais ils ont planté en réponse aux requêtes.

Ce que montre un check depuis l’extérieur Il s’agissait d’équipements grand public, le cas n’a donc aucun rapport avec le produit. Il figure ici uniquement comme exemple allemand de la portée d’une défaillance d’infrastructure.

Source : BSI, Die Lage der IT-Sicherheit in Deutschland 2017, page 15 · The Register, 2016-11-28