Surveiller la disponibilité de vos sites et API avec n8n, sans outil tiers payant

Un site marchand qui répond en erreur 500 pendant quarante minutes un dimanche soir, une API tierce dont dépend un workflow critique qui se met à timeout sans que personne ne le remarque avant le lundi matin : le coût de ces incidents ne tient pas qu'à la durée de la panne, mais à la vitesse de détection. Une étude désormais classique de David A. Patterson, A Simple Way to Estimate the Cost of Downtime (USENIX LISA 2002 — voir sur Google Scholar), pose une méthode simple pour chiffrer ce coût à partir du taux d'indisponibilité et de la valeur horaire de l'activité concernée — et rappelle qu'une minute de panne détectée en une minute coûte objectivement moins qu'une minute de panne détectée en une heure. n8n permet de construire, en quelques nodes, un moniteur de disponibilité qui fait exactement ce travail de détection rapide, sans dépendre d'un service tiers payant.

Un besoin différent de la supervision de votre propre instance n8n

Ce guide ne traite pas de la santé de votre instance n8n elle-même — ce sujet est couvert en détail dans notre article sur la supervision d'une instance n8n self-hosted (endpoint /healthz, métriques Prometheus, heartbeat). Ici, n8n joue un rôle différent : celui de l'outil de supervision, pas de la cible surveillée. C'est un usage fréquent pour une agence qui gère plusieurs sites clients, un indépendant qui veut être prévenu avant ses clients qu'un service est en panne, ou une équipe qui dépend d'une API tierce (paiement, expédition, CRM) dont la disponibilité conditionne ses propres workflows.

Le workflow de base : ping planifié et vérification du statut

Le déclencheur planifié

Un Schedule Trigger réglé en mode Interval, toutes les une à cinq minutes selon la criticité du site surveillé, suffit à démarrer le pipeline. Inutile de descendre sous la minute : au-delà d'une certaine fréquence, vous vous exposez à du rate limiting sur le site cible et le gain en réactivité devient marginal.

Le node HTTP Request

Un node HTTP Request en méthode GET (ou HEAD, plus léger, si le site cible y répond correctement) interroge l'URL surveillée avec :

• un timeout court (5 à 10 secondes) — un site qui répond en 15 secondes est, en pratique, un site en panne pour la majorité de ses visiteurs ;
• Continue On Fail activé, pour que le workflow poursuive même si la requête échoue (timeout, DNS, connexion refusée), au lieu de s'arrêter sans rien faire ;
• la mesure du temps de réponse, disponible dans les métadonnées d'exécution du node, à conserver pour l'historique.

Un node IF évalue ensuite deux conditions : le code de statut HTTP retourné est-il dans la plage attendue (200-299, ou une plage plus large si le site renvoie légitimement des 3xx), et le corps de la réponse contient-il un fragment de texte attendu — un titre, une balise, un mot du footer. Cette seconde vérification attrape les pannes applicatives qui renvoient malgré tout un statut 200, par exemple une page d'erreur générique servie par un CDN en amont.

Éviter les fausses alertes : confirmer avant d'escalader

Un site qui échoue une seule fois sur mille vérifications à cause d'un pic de latence réseau ponctuel ne constitue pas une panne. Escalader au premier échec produit rapidement des alertes que plus personne ne lit sérieusement — le même mécanisme d'usure que celui documenté pour les alertes de supervision applicative. La parade est simple : au lieu d'alerter directement depuis le node IF, incrémentez un compteur d'échecs consécutifs dans une table Supabase (une ligne par site surveillé, avec un champ echecs_consecutifs et un champ statut). N'escaladez en alerte que lorsque ce compteur atteint un seuil (deux ou trois échecs consécutifs, selon la fréquence de vérification), et remettez-le à zéro dès qu'une vérification réussit.

Cette philosophie — vérifier la résilience réelle d'un système plutôt que de se fier à un unique signal instantané — rejoint les travaux fondateurs du chaos engineering chez Netflix : Basiri, Behnam, de Rooij, Hochstein, Kosewski, Reynolds et Rosenthal, Chaos Engineering (IEEE Software, 2016 — voir sur Google Scholar), insistent sur l'importance de distinguer un signal transitoire sans conséquence d'une dégradation réelle du système avant de réagir. Un compteur d'échecs consécutifs applique ce même principe à l'échelle d'un simple pipeline de monitoring.

Alerter sans spammer : incident et rétablissement

Le champ statut de la table (par exemple up ou down) sert de mémoire d'état entre deux exécutions du workflow, ce qui permet de n'envoyer qu'un seul message par transition :

• passage de up à down (après confirmation par le seuil d'échecs) : message d'alerte vers Slack ou Telegram, avec l'URL concernée, le code de statut ou l'erreur rencontrée, et l'heure de première détection ;
• passage de down à up : message de rétablissement, avec la durée totale de l'incident calculée à partir de l'horodatage stocké au moment du passage en down.

Sans cette logique de transition, chaque vérification en échec renverrait un message identique toutes les minutes pendant toute la durée de la panne — exactement le type de bruit qui pousse une équipe à ignorer le canal d'alerte. Pour les incidents les plus critiques, un envoi en parallèle par SMS via le pattern décrit pour les alertes Twilio garantit que le message sort même si l'équipe ne regarde pas Slack un dimanche soir.

Historiser dans Supabase : disponibilité et temps moyen de rétablissement

Chaque exécution, réussie ou non, mérite une ligne dans une table verifications_disponibilite (site, horodatage, statut HTTP, temps de réponse, succès booléen). Cet historique permet de calculer, avec une simple requête SQL :

• le taux de disponibilité sur 30 jours (proportion de vérifications réussies) ;
• le temps de réponse moyen et sa dérive dans le temps, un site qui ralentit progressivement étant souvent le signe avant-coureur d'un incident plus sérieux ;
• le MTTR (temps moyen de rétablissement), en croisant les horodatages des transitions down → up.

C'est précisément le type de piste d'audit que couvre déjà le Pack Conformité & Audit (149 €), dont la table Supabase append-only et les rapports de synthèse générés par IA s'adaptent sans grand effort à un usage de suivi de disponibilité plutôt que de conformité réglementaire.

Bonus : surveiller aussi l'expiration du certificat SSL

Un certificat SSL qui expire un samedi matin coupe l'accès au site aussi sûrement qu'une panne serveur — et c'est un incident entièrement prévisible. Un node Code appelé une fois par jour (pas à chaque ping) peut interroger la date d'expiration du certificat via une requête TLS et déclencher une alerte dès que l'échéance tombe sous 14 jours, laissant largement le temps de renouveler avant la coupure.

Les limites à connaître

Ce pipeline dépend intégralement de la disponibilité de votre propre instance n8n : si elle est hors ligne en même temps que le site surveillé, ou avant lui, aucune alerte ne part. Pour un enjeu réellement critique, gardez toujours une sonde externe indépendante en complément — le guide de supervision d'instance n8n explique comment sécuriser ce maillon avec un heartbeat vers un service tiers gratuit. Un Error Workflow dédié sur ce pipeline de monitoring lui-même est également recommandé : le workflow qui vous prévient des pannes ne doit pas être celui qui échoue en silence.

Pour aller plus loin

Ce pipeline se construit avec les nodes déjà présents dans n8n, sans dépendance externe autre que Slack ou Telegram pour l'alerte. Si vous cherchez un socle de workflows n8n déjà conçus avec cette rigueur — journalisation Supabase append-only, alertes structurées, gestion d'erreurs intégrée — le Pack Conformité & Audit (149 €) et, pour l'ensemble des cas d'usage du site, le Bundle FlowKit Complet (269 €) évitent de repartir de zéro.