Surveillance de site web : webhooks
Uptimia vérifie vos sites, vos certificats et vos parcours de paiement depuis l’extérieur de votre réseau et appelle votre point de terminaison à chaque panne confirmée. Votre propre code décide de la suite — ouvrir un ticket, redémarrer un service, alimenter un tableau de bord — et chaque vérification envoie le même format, si bien que vous écrivez le gestionnaire une seule fois.
Authorization: Bearer •••••••••••••••• Content-Type: application/json { "id": 3517, "monitor_type": "uptime", "monitor_name": "Checkout — caldmont.com", "monitor_unique_id": "checkout-prod", "monitor_status": "down", "severity": "critical", "incident_start_time": "2026-07-30T11:47:12+02:00", "incident_end_time": "", "incident_duration_seconds": 0, "message": "*ALERT*: Project Checkout — caldmont.com is DOWN", "monitor_notes": "Failover: drain eu-west-2 first" }
Pas un message, un contrat
Tous les autres canaux se terminent chez une personne, et les personnes sont des lecteurs indulgents. Le code ne l’est pas — c’est pourquoi l’essentiel n’est jamais la charge utile, mais les garanties qui la soutiennent.
« Quelque chose a cassé » — à vous de reconstituer le reste
La formulation peut dériver d’une version à l’autre, parce que le lecteur s’adapte. Dès qu’un logiciel en dépend, cette approximation devient un défaut dans votre intégration.
Onze champs, cinq relances, une structure
Un seul objet pour chaque type de vérification : un gestionnaire à écrire, une distinction sur deux champs. C’est relancé cinq fois avant d’être abandonné, donc des doublons sont possibles — documentés plutôt que découverts.
L’alerte atterrit dans votre propre code
Une vérification échoue et Uptimia appelle votre point de terminaison avec les détails, déjà confirmés. Votre propre automatisation décide de la suite — ici, un ticket qui s’ouvre tout seul et se ferme au rétablissement.
Connecter un webhook en trois étapes
Aucune application à autoriser, aucune bibliothèque à installer — Uptimia a seulement besoin d’une URL à appeler et, si le point de terminaison est protégé, d’un en-tête qui l’y fait entrer.
Collez l’URL de votre point de terminaison
C’est toute l’inscription — une seule URL publique.
Ajoutez vos en-têtes d’authentification
Facultatif — les en-têtes sont envoyés exactement tels que vous les écrivez, si bien qu’un simple jeton ouvre la porte à Uptimia.
Associez-y vos sondes
Choisissez les vérifications qui doivent l’appeler, et une livraison test prouve le branchement avec le format réel.
Enregistrer un point de terminaison webhook
Le centre d’aide couvre la mise en œuvre : ajouter l’URL, écrire les en-têtes personnalisés, envoyer un POST test, et lire ce qu’une livraison échouée vous indique.
Chaque type de vérification. Une seule structure.
Un certificat qui expire, une tâche planifiée qui ne s’est jamais signalée et un serveur au-dessus de son seuil de CPU arrivent tous comme le même objet plat. Deux champs les distinguent.
Passerelles de chat, lignes de base de données, actions automatisées
Une fois qu’un incident est un objet que votre code a accepté, les usages utiles ne ressemblent plus à des alertes.
Les autres canaux informent une personne.Celui-ci informe votre code.
Toute la plateforme pendant l’essai — tous les types de vérification, plus de 171 points de contrôle, et chaque incident confirmé livré comme un objet qui vous appartient.
Les garanties de livraison, noir sur blanc
Personne ne peut écrire un gestionnaire fiable contre « nous vous enverrons une notification ». Voici les garanties réelles.
Au moins une fois, avec cinq relances
Dix secondes pour répondre, et tout 2xx compte comme accepté. Tout le reste est remis en file et relancé cinq fois, chaque attente une minute plus longue que la précédente, puis abandonné — répondez donc d’abord, et faites le travail ensuite.
Un objet plat, onze clés
Pas d’imbrication, pas d’enveloppe, pas de schéma qui change selon le type de vérification. Deux champs les distinguent; les neuf autres ne changent jamais de sens — dont monitor_notes, la ligne de runbook laissée par la personne qui a configuré la sonde.
Une vague de pannes ajoute une clé
Les sondes qui tombent en panne ensemble deviennent une seule requête avec un objet de groupe supplémentaire — membres, décompte, acquittement. Les gestionnaires qui l’ignorent continuent de fonctionner.
Vos en-têtes, transmis tels quels
Envoyés mot pour mot, si bien qu’un jeton porteur ou un secret partagé fonctionne. Il n’y a pas de signature du corps : vérifiez l’en-tête côté serveur, et gardez l’URL secrète.
Là où ça refusera de publier
Uniquement http(s) public; le loopback et les plages privées sont rejetés. L’adresse est résolue une fois puis fixée, les redirections sont ignorées, TLS est vérifié.
Aucun lien d’acquittement — volontairement
Les canaux que lit une personne portent un lien signé qui arrête l’échelle. Les systèmes reçoivent les faits et rien d’autre — un pipeline de journalisation qui peut faire taire une alerte finira par le faire.
Comment fonctionnent les webhooks de surveillance
Uptimia vérifie vos sites web depuis plus de 171 emplacements externes et, quand une vérification échoue, envoie une requête HTTP POST avec un corps JSON vers l’URL que vous avez enregistrée. Le même objet plat arrive pour chaque type de vérification — quelle sonde, ce qui s’est passé, quand et pendant combien de temps — si bien qu’un seul gestionnaire les couvre tous, et les livraisons échouées sont relancées.
Le bug que tout le monde écrit le premier jour
Rétablissements, avertissements et tests partagent un même point de terminaison. monitor_status vaut down, up ou test; severity vaut critical ou trouble, et vide lors d’un rétablissement. Testez les deux.
Confirmé avant que votre code n’en entende parler
Une automatisation n’est fiable que par son déclencheur. Une vérification web n’est jamais alertée sur l’opinion d’un seul point de contrôle — une panne suspectée est d’abord retestée depuis d’autres sondes.
Onze champs, chaque événement
Ce qui est toujours présent, et ce qu’il contient.
Voir tous les canaux d’alerte →| Champ | Exemple | Ce qu’il contient |
|---|---|---|
| id | 4172 | L’identifiant numérique de la sonde dans Uptimia |
| monitor_type | uptime | Quel type de vérification s’est déclenché |
| monitor_name | Dispatch API | Le nom que vous lui avez donné (le nom du site pour les vérifications de disponibilité) |
| monitor_unique_id | dispatch-api-eu | Votre propre identifiant — la clé de jointure |
| monitor_status | down | down, up ou test |
| severity | critical | critical ou trouble — vide lors d’un rétablissement |
| incident_start_time | 2026-07-24T02:17:04+02:00 | ISO 8601, fuseau horaire du compte |
| incident_end_time | 2026-07-24T02:31:07+02:00 | Vide tant que l’incident est ouvert |
| incident_duration_seconds | 843 | Zéro jusqu’à la fermeture de l’incident |
| message | *ALERT*: Project … is DOWN | Le résumé d’une ligne que reçoivent les autres canaux |
| monitor_notes | Failover: drain eu-west-2 first | La note de la sonde — vide si personne n’en a écrit |
FAQ sur les webhooks personnalisés
01Qu’envoyez-vous exactement ?+
02Comment authentifier la requête ?+
03Que se passe-t-il si mon point de terminaison est lent ou hors service ?+
04Vais-je un jour recevoir le même événement deux fois ?+
05Puis-je le pointer vers localhost ou une adresse interne ?+
06Suivez-vous les redirections ?+
07Que se passe-t-il quand plusieurs sondes tombent en panne en même temps ?+
08Mon gestionnaire peut-il acquitter, ou répondre ?+
09Que publie réellement « Envoyer un test » ?+
10Combien de points de terminaison puis-je avoir, et est-ce inclus ?+
Une URL, chaque incident confirmé
Enregistrez un point de terminaison, associez-le aux sondes qui comptent, et chaque panne confirmée arrive comme un objet que vos systèmes peuvent archiver et exploiter.