Pourquoi vos outils de monitoring ne détectent pas les échecs silencieux

Les pannes pour lesquelles personne n'est alerté

Vos tableaux de bord sont au vert. Les checks de disponibilité passent, l'application répond, le CPU est tranquille. Et pourtant la sauvegarde nocturne n'a pas écrit un seul octet depuis neuf jours, le cron de facturation a été supprimé lors d'un déploiement il y a trois semaines, et le worker qui synchronise les commandes est mort en silence après une exception non gérée. Rien n'est apparu nulle part, parce que rien n'a produit d'erreur que quelqu'un surveillait. Vous l'apprenez quand un client demande où sont passées ses données, ce qui est le pire moment pour découvrir qu'un job a cessé de tourner le mois dernier.

Ce sont des échecs silencieux : un travail censé se produire, qui n'a pas eu lieu, et qui n'a prévenu personne. Ce ne sont pas des cas rares. C'est le mode d'échec par défaut de tout ce qui tourne à intervalle régulier sans qu'un humain regarde.

Pourquoi le monitoring basé sur les erreurs a un angle mort

Le monitoring classique est construit autour d'événements. Une exception est levée, un health check renvoie 500, un disque dépasse 90 %, et une alerte se déclenche. Il est réellement efficace pour attraper ce qui échoue bruyamment. L'angle mort est structurel, ce n'est pas une question de réglage : un moniteur ne peut alerter que sur les signaux qu'il reçoit effectivement.

Un job qui ne démarre jamais n'envoie aucun signal. Un processus tué en cours d'exécution par l'OOM killer n'envoie aucun signal. Une entrée crontab supprimée en silence par un mauvais déploiement n'envoie aucun signal. Il n'y a rien sur quoi se déclencher, donc tout reste au vert. L'absence d'échec n'est pas la même chose qu'un succès, mais pour un système basé sur les erreurs, les deux sont indiscernables : les deux ressemblent à un tableau de bord calme et en bonne santé.

À quoi ressemble vraiment un échec silencieux

Aucun de ces cas n'est exotique. Chacun est un mardi ordinaire quelque part :

• Un script de sauvegarde qui renvoie le code 0 après que le disque s'est rempli, ayant écrit une archive tronquée ou vide que personne ne découvrira avant la restauration.
• Un rapport planifié qui a cessé de tourner le jour où le mot de passe de son utilisateur cron a expiré.
• Un job de renouvellement de certificat supprimé lors d'une migration de serveur, qui avance en silence vers sa date d'expiration.
• Une synchronisation de données qui plante sur le premier enregistrement et avale l'exception, si bien que le pipeline « réussit » chaque nuit avec zéro ligne.

Chacun de ces cas est invisible pour un moniteur qui attend une erreur, parce que l'erreur soit ne s'est jamais produite, soit n'a jamais quitté la machine.

Inversez le signal, et le silence devient l'alarme

Un dead man's switch (aussi appelé moniteur de type heartbeat ou check-in) inverse la logique. Vous indiquez à Mortemain à quelle fréquence un job doit se signaler, et quel retard reste acceptable. Le job effectue une requête HTTP quand il se termine. Tant que ce check-in continue d'arriver à l'heure, le check reste au vert. Dès qu'il est en retard au-delà de sa fenêtre, Mortemain vous alerte, sans que le job ait besoin de remarquer ou de signaler quoi que ce soit lui-même.

# la dernière chose que fait votre job
curl -fsS -m 10 https://ping.mortemain.com/your-check-uuid

Un cron supprimé, un worker mort, un hôte qui n'est jamais remonté : tous cessent simplement de se signaler. Le silence est l'événement. C'est exactement la classe de pannes que le monitoring basé sur les erreurs ne peut jamais voir, parce qu'elle se définit par l'absence d'un signal plutôt que par la présence de l'un d'eux.

Comment Mortemain comble ce vide

Le check-in sur succès est toute la fondation, et deux signaux optionnels l'affinent :

• Le check-in prouve que le job est arrivé au bout. S'il manque, le check passe en panne après son délai de grâce.
• /fail, appelé depuis votre gestionnaire d'erreurs, force le check en panne immédiatement au lieu d'attendre l'expiration de la fenêtre : un job qui échoue bruyamment vous alerte quand même aussitôt.
• /start, appelé au démarrage du job, permet à Mortemain de mesurer la durée de chaque exécution : un job qui dure soudain quatre fois plus longtemps devient un avertissement avant de devenir une panne.

Aucun agent à installer, aucun SDK à importer. C'est une requête HTTP qu'une tâche cron, une tâche PowerShell, un script Python ou un conteneur peuvent tous déjà faire. Mortemain est hébergé uniquement dans l'UE, les métadonnées de check-in restent donc en France et en Allemagne.

Commencez par le job qui vous manquerait en premier

Choisissez le job dont l'échec silencieux ferait le plus mal, votre sauvegarde nocturne, votre run de facturation, votre export de données, et donnez-lui un check-in cet après-midi. Voici la ligne exacte pour les outils que vous utilisez déjà :