Un contrôle de disponibilité fonctionne en mode pull : un service de surveillance envoie une requête à votre site ou à votre API à intervalles réguliers et vous alerte quand la réponse est incorrecte ou absente. Un heartbeat fonctionne en mode push : votre tâche ou votre service envoie une requête au service de surveillance à chaque exécution, et l’alerte se déclenche quand cette requête n’arrive pas. Utilisez les contrôles de disponibilité pour tout ce que l’on atteint par le réseau, et les heartbeats pour les traitements planifiés ou sans adresse publique. La plupart des infrastructures ont besoin des deux.
On les confond facilement, car les deux se résument à « alerter quand quelque chose ne va pas ». Pourtant, ils ne voient pas les mêmes pannes, et utiliser l’un là où il faudrait l’autre crée un angle mort qui ne se révèle qu’au moment où quelque chose casse.
Comment fonctionne un contrôle de disponibilité
C’est le service de surveillance qui joue le rôle du client. Chaque minute, ou à l’intervalle de votre choix, il appelle une URL, envoie un ping à un hôte ou ouvre un port, puis évalue la réponse : le code de statut, le temps de réponse, un mot-clé dans la page, le certificat. Si le contrôle échoue et qu’un second contrôle le confirme, vous recevez une alerte. C’est une forme de monitoring synthétique : un robot fait ce que ferait un visiteur.
Ce qu’il détecte : un site ou une API en panne, lent, qui renvoie des erreurs, affiche le mauvais contenu ou est cassé par un certificat expiré ou une modification DNS. Tout ce qu’un visiteur rencontrerait.
Ce qu’il manque : tout ce qui ne répond pas à des requêtes. Une sauvegarde qui ne s’est pas lancée, un worker de file d’attente bloqué, un import qui a échoué à 02:00. Le site reste en ligne, donc tous les contrôles passent.
Comment fonctionne un heartbeat
Ici, c’est votre tâche qui joue le rôle du client. Vous indiquez au service de surveillance quand la tâche doit s’exécuter, et la tâche appelle une URL de ping unique à la fin de son exécution. Si le ping a plus de retard que le délai de grâce choisi, vous recevez une alerte. Le principe est celui de l’homme mort : c’est le silence qui donne l’alerte. C’est pourquoi le monitoring par heartbeat est aussi appelé surveillance push ou surveillance « dead man’s switch ».
0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 –retry 3 -o /dev/null https://app.uptimecheck.com/api/hb/your-token
Ce qu’il détecte : les tâches qui n’ont pas démarré, qui ont planté avant la fin, qui ont tourné selon le mauvais planning ou, avec un ping de démarrage, qui ont duré beaucoup trop longtemps. Avec un code de sortie dans le ping, il détecte aussi les tâches qui se sont exécutées mais ont échoué.
Ce qu’il manque : la question de savoir si quelqu’un peut atteindre votre service. Une tâche sur un serveur peut envoyer ses pings sans problème pendant que le site hébergé sur ce même serveur répond 502 à chaque visiteur.
Comparaison directe
Contrôle de disponibilitéHeartbeatQui envoie la requêteLe service de surveillanceVotre tâche ou votre serviceAlerte quandLa réponse est incorrecte, lente ou absenteLe ping est en retard ou signale un échecAdresse publique nécessaireOuiNon, seulement du HTTPS sortantConfigurationUne URL, un hôte ou un portUn planning, un délai de grâce et une requête dans la tâcheVoitCe que vivent les visiteurs et les clients de l’APISi les traitements en arrière-plan ont tourné et comment ils se sont terminésAveugle àCe qui ne répond pas à des requêtesLa possibilité d’atteindre le service
Quand utiliser un contrôle de disponibilité
Votre page d’accueil et les pages qui génèrent du chiffre d’affaires : paiement, inscription, connexion.
Les API publiques et les récepteurs de webhooks, avec des vérifications sur le code de statut et le JSON renvoyé.
Un endpoint de health check qui teste la base de données et les autres dépendances à chaque requête.
Les services sur d’autres ports, comme un serveur mail, avec un contrôle de port.
La règle simple : si une personne ou un autre système l’appelle, contrôlez-le depuis l’extérieur, comme eux.
Quand utiliser un heartbeat
Les tâches cron : sauvegardes de bases de données et de fichiers, imports et exports nocturnes, génération de rapports, facturation.
Les tâches planifiées sous d’autres formes : une tâche planifiée Windows, un CronJob Kubernetes, un workflow GitHub Actions planifié, une fonction serverless déclenchée par un minuteur.
Les scripts de renouvellement de certificats et les synchronisations de données entre systèmes.
Tout ce qui se trouve derrière un pare-feu ou un NAT, inaccessible depuis l’extérieur, mais capable d’émettre une requête HTTPS sortante.
Workers de longue durée
Un worker de file d’attente ou un daemon ne suit pas de planning, mais il peut tout de même envoyer un heartbeat. Envoyez un ping depuis la boucle principale toutes les quelques minutes et donnez au moniteur un intervalle plutôt qu’une expression cron. Si la boucle se bloque, si le processus est tué ou si le serveur redémarre sans le relancer, les pings s’arrêtent et vous êtes prévenu. Envoyez le ping depuis la boucle qui fait le travail, pas depuis un thread séparé, sinon un worker bloqué continuera d’affirmer que tout va bien.
Quand il vous faut les deux
La plupart des services réels ont une vitrine et une arrière-boutique. Surveillez chacune avec l’outil qui la voit :
Une boutique en ligne : des contrôles de disponibilité sur la page d’accueil et le tunnel de paiement, et des heartbeats sur l’export nocturne des commandes et la sauvegarde de la base de données.
Un produit SaaS : un contrôle de disponibilité sur l’endpoint de santé de l’API, et des heartbeats sur le worker de file d’attente et la tâche qui envoie les factures.
Un service interne : pas d’adresse publique, donc un heartbeat envoyé par le service lui-même, plus des contrôles de disponibilité sur les pages publiques qui dépendent de ses données.
Une alternative consiste à exposer l’état des tâches via l’endpoint de santé, par exemple en faisant échouer le contrôle quand la dernière sauvegarde date de plus de 25 heures. Cela fonctionne, mais lie la disponibilité de votre site à vos sauvegardes : une sauvegarde en retard apparaît comme une indisponibilité du site dans vos rapports. Un heartbeat séparé garde les deux signaux distincts, tout comme les personnes qui reçoivent chaque alerte.
Bien régler les délais
Intervalle du contrôle de disponibilité : chaque minute pour les pages qui génèrent du chiffre d’affaires, car l’intervalle correspond à la durée maximale pendant laquelle une panne peut vous échapper. Les pages moins critiques peuvent utiliser un intervalle plus long.
Délai de grâce du heartbeat : plus long que la variation normale de l’heure de fin de la tâche. Une sauvegarde qui démarre à 03:00, dure de 5 à 20 minutes et envoie son ping à la fin a besoin d’au moins 20 minutes de grâce ; 30 laissent de la marge pour une nuit plus lente.
Durée d’exécution maximale : avec un ping de démarrage, soyez alerté quand une exécution dure bien plus longtemps que d’habitude. Une tâche bloquée n’envoie pas non plus son ping de fin, mais cette alerte arrive dès que la limite est dépassée.
Fuseau horaire : un planning cron s’exécute dans le fuseau horaire du serveur, souvent UTC. Donnez le même au moniteur, sinon le changement d’heure lui fera attendre la tâche une heure trop tôt ou trop tard deux fois par an. L’outil d’expressions cron montre quand un planning s’exécute réellement.
Erreurs courantes
Envoyer le ping uniquement au démarrage. Une tâche qui démarre puis plante s’est quand même signalée. Envoyez le ping à la fin, ou les deux.
Envoyer le ping même quand la tâche échoue. backup.sh; curl … envoie le ping quoi qu’il arrive. Utilisez &&, ou envoyez le code de sortie pour qu’un échec soit signalé comme tel.
Un ping qui peut bloquer la tâche. Donnez à curl un timeout et des tentatives (-m 10 –retry 3), pour qu’un réseau lent ne bloque pas la tâche et ne fasse pas perdre le ping.
Utiliser un heartbeat pour un site public. Un serveur qui envoie des pings prouve seulement qu’il peut atteindre Internet, pas que les visiteurs peuvent l’atteindre.
Surveiller le daemon cron plutôt que la tâche. Le daemon peut tourner parfaitement pendant qu’une tâche échoue chaque nuit. Chaque tâche importante a droit à son propre heartbeat.
Pour aller plus loin côté heartbeat : comment surveiller vos tâches cron et comment éviter les tâches cron manquées.
Les deux au même endroit avec Uptimecheck
Uptimecheck gère les deux types de moniteurs dans le même compte, avec les mêmes canaux d’alerte et le même historique d’incidents.
Surveillance de disponibilité : contrôles HTTP(S), ping et port jusqu’à chaque minute depuis Stockholm, Londres et New York, chaque échec étant confirmé depuis un second site avant toute alerte. Les contrôles HTTP peuvent vérifier le code de statut, un mot-clé, des champs JSON et des en-têtes.
Surveillance des tâches cron : une expression crontab dans votre fuseau horaire, changement d’heure compris, ou un simple intervalle ; un délai de grâce de 1 minute à 6 heures ; des pings /start avec une durée d’exécution maximale de 1 minute à 24 heures ; /fail ou le code de sortie pour indiquer comment une exécution s’est terminée ; et la sortie de la tâche, envoyée avec le ping, affichée dans l’alerte.
Limites : Start inclut 15 moniteurs de disponibilité et 10 tâches cron, Professional 100 et 50, Business 250 et 150. Voir les tarifs.
Pour en configurer un, consultez comment surveiller une tâche cron avec un heartbeat et les exemples de ping pour tâches cron pour Laravel, Kubernetes, GitHub Actions, systemd et Windows. Pour les disques et la mémoire du serveur sous-jacent, ajoutez la surveillance de serveurs.
Surveillez la vitrine et l’arrière-boutique. Essayez Uptimecheck gratuitement pendant 14 jours, sans carte bancaire.