Comment auto-héberger Healthchecks en 2026 : pings cron, alertes et sauvegardes de base de données

L’auto-hébergement de Healthchecks devient intéressant dès le premier redeploy, et non au premier docker run. Si les tâches cron envoient un ping vers une URL interne ou si les workers d’e-mails ne sont pas actifs, Docker peut malgré tout signaler un processus parfaitement sain. Le déploiement ci-dessous repose sur un comportement observable : envoyer des pings de démarrage, de réussite et d’échec depuis une tâche de test, puis omettre un ping planifié et recevoir l’alerte de tâche manquante.

La fonction de Healthchecks est claire : surveiller les tâches cron et les tâches exécutées en arrière-plan à l’aide d’un mécanisme dead-man. Cette description indique ce qui doit rester public, ce qui doit rester privé et ce qu’une sauvegarde doit pouvoir reconstituer.

Sauvegardez l’état que Healthchecks ne peut pas recréer

Le conteneur Healthchecks standard ne nécessite aucun montage de données applicatives. Son périmètre de récupération reste néanmoins explicite : la base de données de l’application et la configuration des notifications. Ne créez pas un volume vide simplement pour donner l’impression que le déploiement est stateful ; conservez plutôt la référence exacte de l’image et la configuration validée.

Reconstruisez Healthchecks sur un hôte vierge et exécutez la transaction d’acceptation. La récupération est réussie lorsque les checks, les planifications, les intégrations et les clés de ping sont restaurés, et qu’un ping volontairement omis déclenche l’alerte attendue. Toute base de données connectée ou tout service collaboratif suit son propre plan de sauvegarde cohérent avec l’application, tandis que le conteneur web remplaçable est recréé à partir du code. Le guide de déploiement de Git à la production décrit cette frontière reproductible.

Conservez une checksum ou un digest pour l’image validée et retestez après chaque mise à jour. Pour un service stateless, une reconstruction réussie constitue le test de restauration ; pour les données externes, le runbook Healthchecks doit pointer vers le propriétaire et la procédure de récupération dédiés.

Construisez un conteneur Healthchecks remplaçable

Utilisez une commande qui expose chaque choix important. Cette configuration de référence lie Healthchecks à la loopback de l’hôte, ajoute les montages de données connus et fournit le premier paramètre requis. Ajoutez les paramètres de connexion validés pour Postgres ainsi qu’un service d’envoi d’e-mails opérationnel pour les alertes de production ; utilisez des noms privés pour les services privés.

docker run -d \
  --name healthchecks \
  --restart unless-stopped \
  -p 127.0.0.1:8000:8000 \
  -e SECRET_KEY=replace-with-a-long-random-value \
  -e SITE_ROOT=https://app.example.com \
  -e ALLOWED_HOSTS=app.example.com \
  -e DB=postgres \
  -e DB_HOST=postgres.internal \
  -e DB_NAME=healthchecks \
  -e DB_USER=healthchecks \
  -e DB_PASSWORD=replace-with-a-strong-database-password \
  healthchecks/healthchecks:latest

Remplacez les tags flottants par une version testée ou un digest. Après le démarrage, inspectez docker logs --tail 200 healthchecks et vérifiez que le processus écoute sur le port 8000. Exécutez ensuite l’action d’acceptation Healthchecks ; la réponse de la page d’accueil ne suffit pas à prouver que le scénario complet fonctionne : envoyez des pings de démarrage, de réussite et d’échec depuis une tâche de test, puis omettez un ping planifié et recevez l’alerte de tâche manquante.

Les dépendances de Healthchecks

Tracez trois frontières autour de Healthchecks : l’ingress vers le port 8000, l’état durable et les exigences de support. Le conteneur est remplaçable, mais les deux autres éléments nécessitent des propriétaires explicites. Le contrat réseau de Healthchecks repose sur Postgres et sur un service d’envoi d’e-mails opérationnel pour les alertes de production. Conservez les endpoints privés dans le DNS interne, n’autorisez que les appels sortants nécessaires et attribuez à Healthchecks un identifiant de service aux permissions limitées.

Le diagramme est complet lorsqu’un client vierge peut envoyer des pings de démarrage, de réussite et d’échec depuis une tâche de test, puis omettre un ping planifié et recevoir l’alerte de tâche manquante. Collectez les données de durée et de ressources pour le nombre de checks, les périodes de grâce, la diffusion des notifications, l’envoi des e-mails et les écritures en base de données. Si la transaction échoue, la première frontière qui ne se comporte pas comme prévu indique s’il faut examiner le routage, la capacité locale ou un service de support.

Acheminez Healthchecks sans donner une fausse impression d’HTTPS

Choisissez le hostname final de Healthchecks avant que les utilisateurs n’enregistrent des callbacks ou des paramètres client, puis définissez SITE_ROOT et ALLOWED_HOSTS sur l’adresse HTTPS externe. La route de la plateforme doit terminer TLS une seule fois et cibler le port privé 8000.

Exécutez la transaction d’acceptation depuis l’extérieur. Si le client n’atteint jamais Healthchecks, utilisez la checklist de validation SSL pour vérifier le DNS et le certificat. Si la requête atteint Healthchecks, mais que les tâches cron envoient un ping vers une URL interne ou que les workers d’e-mails ne sont pas actifs, cessez de modifier les redirections du proxy et examinez plutôt la frontière propre à l’application.

Éléments à recueillir avant la mise en production de Healthchecks

Créez un petit fixture Healthchecks jetable et conservez-le pour chaque release. Le fixture doit reproduire le workflow réel : envoyer des pings de démarrage, de réussite et d’échec depuis une tâche de test, puis omettre un ping planifié et recevoir l’alerte de tâche manquante. Notez le digest de l’image, le hostname externe, l’adresse de la dépendance et le résultat attendu afin qu’un autre opérateur puisse répéter le test sans devoir interpréter ce guide.

Exécutez le fixture trois fois. Premièrement, utilisez le déploiement fraîchement installé. Deuxièmement, remplacez le conteneur sans toucher à l’état durable. Troisièmement, restaurez la sauvegarde dans un environnement vide. Le troisième run est réussi uniquement lorsque les checks, les planifications, les intégrations et les clés de ping sont restaurés, et qu’un ping volontairement omis déclenche l’alerte attendue. À chaque run, mesurez la latence et l’utilisation des ressources autour du nombre de checks, des périodes de grâce, de la diffusion des notifications, de l’envoi des e-mails et des écritures en base de données ; ces données constituent la baseline des alertes, plutôt qu’un pourcentage de CPU choisi arbitrairement.

Enfin, testez volontairement le chemin négatif : refusez temporairement à l’identité de test l’accès à Postgres et à un service d’envoi d’e-mails opérationnel pour les alertes de production. Vérifiez que Healthchecks échoue de manière visible sans corrompre l’état, rétablissez les conditions correctes et répétez la transaction réussie. Un enregistrement de release contenant ces quatre résultats constitue une preuve plus solide que des captures d’écran d’un dashboard ou qu’une réponse curl ponctuelle.

Exercices de panne pour Healthchecks

Observez le travail effectué par Healthchecks : nombre de checks, périodes de grâce, diffusion des notifications, envoi des e-mails et écritures en base de données. Définissez des limites avec une marge suffisante pour cette charge et évitez une liveness probe qui entrerait en concurrence avec elle. Le check opérateur doit toujours tenter d’envoyer des pings de démarrage, de réussite et d’échec depuis une tâche de test, puis omettre un ping planifié et recevoir l’alerte de tâche manquante selon une planification.

Pour les mises à jour, n’oubliez pas que les migrations de l’application et la configuration des workers doivent être mises à niveau ensemble afin que la page web ne masque pas une livraison d’alertes défaillante. Déployez le candidat sur une copie restaurée et répétez le test connu. Si les tâches cron envoient un ping vers une URL interne ou si les workers d’e-mails ne sont pas actifs, utilisez les logs d’exécution et la requête réseau réelle pour déterminer quelle hypothèse a changé.

Définissez la frontière de confiance de Healthchecks

Fermez la fenêtre de bootstrap dès que le premier administrateur de confiance existe. Le piège concret de Healthchecks consiste à utiliser un secret généré qui change à chaque redémarrage ; la frontière la plus sûre consiste à utiliser une SECRET_KEY stable, à limiter l’appartenance aux projets et à traiter les URLs de ping comme des identifiants.

Générez SECRET_KEY une seule fois, ne la stockez pas dans Git et conservez-la avec le manifest de récupération, car sa modification peut invalider l’état applicatif chiffré ou signé. Le réseau privé doit transporter les identifiants des dépendances, et les rôles au sein de Healthchecks doivent accorder uniquement l’action utile minimale. Évitez de faire apparaître les corps de requête sensibles et les réponses des fournisseurs dans les logs courants.

Un déploiement Dockup nécessite toujours un test d’acceptation Healthchecks

Dockup peut prendre en charge les composants remplaçables de la plateforme : acheminer le trafic vers le port 8000, fournir le domaine et le certificat, injecter les secrets, attacher le stockage persistant et connecter Healthchecks à des services gérés ou attachés au réseau privé. Ces opérations peuvent être réalisées sur l’infrastructure Dockup ou sur un serveur que vous rattachez.

Le travail d’acceptation de Healthchecks reste explicite. Après le déploiement en un clic, définissez SITE_ROOT et ALLOWED_HOSTS sur l’adresse HTTPS externe, connectez et testez Postgres ainsi qu’un service d’envoi d’e-mails opérationnel pour les alertes de production, puis exécutez ce scénario : envoyez des pings de démarrage, de réussite et d’échec depuis une tâche de test, puis omettez un ping planifié et recevez l’alerte de tâche manquante. Cette séparation est volontaire : Dockup supprime la configuration répétitive de l’infrastructure sans prétendre que les rôles applicatifs, les identifiants des fournisseurs ou la stratégie de restauration se choisissent automatiquement.

Foire aux questions

De quoi Healthchecks a-t-il besoin pour un déploiement en production ?

Acheminez le conteneur Healthchecks sur le port 8000 via une origine HTTPS unique. L’exigence réseau de support est Postgres ainsi qu’un service d’envoi d’e-mails opérationnel pour les alertes de production. Ne considérez pas Healthchecks comme prêt tant que vous ne pouvez pas envoyer des pings de démarrage, de réussite et d’échec depuis une tâche de test, puis omettre un ping planifié et recevoir l’alerte de tâche manquante.

Quelles données Healthchecks doivent figurer dans une sauvegarde ?

L’image Healthchecks standard ne nécessite aucun montage de données applicatives. Préservez sa configuration de déploiement et sauvegardez séparément les données connectées ; la récupération est réussie lorsque les checks, les planifications, les intégrations et les clés de ping sont restaurés, et qu’un ping volontairement omis déclenche l’alerte attendue.

Healthchecks nécessite-t-il HTTPS derrière un reverse proxy ?

Utilisez HTTPS pour l’origine publique de Healthchecks et conservez le port 8000 sur la route interne. Appliquez correctement le paramètre Healthchecks : définissez SITE_ROOT et ALLOWED_HOSTS sur l’adresse HTTPS externe. Pour Healthchecks, HTTPS protège les identifiants ou le contenu utilisateur pendant leur transport et garantit un comportement cohérent des clients sensibles à l’origine.

Comment tester une mise à niveau de Healthchecks ?

Restaurez l’état actuel de Healthchecks dans un déploiement isolé, appliquez la version candidate et répétez sa transaction d’acceptation. Soyez particulièrement attentif, car les migrations de l’application et la configuration des workers doivent être mises à niveau ensemble afin que la page web ne masque pas une livraison d’alertes défaillante. Conservez l’image Healthchecks précédente jusqu’à ce que les limites de migration des données et de rollback soient comprises.