Une tâche cron qui échoue peut vous le dire : le guide cron envoie un push quand une tâche se termine en erreur. Une tâche qui ne s’exécute pas du tout, elle, ne dit rien. La ligne de crontab s’est perdue lors d’un changement de serveur, la machine est éteinte, le démon cron s’est arrêté, ou la tâche est bloquée et ne se termine jamais. Rien n’échoue, donc rien n’est envoyé, et vous l’apprenez le jour où vous avez besoin de la sauvegarde de la nuit.

Un signal de vie (heartbeat, en anglais) inverse la logique, d’où son autre nom de « dead man’s switch », le dispositif de l’homme mort. La tâche appelle une URL à chaque exécution. Honk sait à quel rythme attendre cet appel et, s’il ne vient pas, ouvre un problème et vous prévient sur iPhone, sur Apple Watch ou dans le navigateur. L’appel suivant le clôt. C’est le principe de base de toute surveillance de tâches cron.

Comment fonctionne un signal de vie

Vous fixez un intervalle : le rythme auquel un signal doit arriver, de 1 minute à 1 semaine.
Et une marge : le délai supplémentaire toléré avant que Honk ne déclare le signal en retard, 5 minutes par défaut. L’échéance, c’est le dernier signal, plus l’intervalle, plus la marge.
Chaque signal de vie a une URL secrète, https://honk-honk.app/hb/…. Une requête GET, POST ou HEAD vers cette URL compte comme un signal, sans clé ni en-tête.
Quand l’échéance est dépassée, Honk ouvre un problème dans le projet, un Klaxon long sauf si vous choisissez un autre niveau. Il s’intitule « Sauvegarde de nuit est en retard », avec le message « Aucun signal depuis 2026-10-14 03:12 UTC. Attendu toutes les 1 j (+5 min de marge). » Honk vérifie au moins une fois par minute.
Une panne, un seul problème. Tant que la tâche reste muette, Honk n’ajoute rien : pas de nouveau push chaque minute.
Le signal suivant le clôt avec un rétablissement, « Sauvegarde de nuit est de retour », envoyé comme n’importe quel push.

Le problème est un événement Honk ordinaire, dans le groupe heartbeat/<slug> : heures calmes, mises en sourdine, Activités en direct et règles s’y appliquent comme au reste. Un nouveau signal attend son premier appel et ne peut pas être en retard avant.

Avant de commencer

Un compte Honk et un projet. Honk est pour l’instant sur invitation : demandez un accès si besoin.
Le droit de gérer le projet. Les propriétaires et administrateurs de l’espace de travail l’ont.
De la place pour un signal de plus : un espace de travail peut en avoir 2 avec le forfait Free, 20 avec Pro et 100 avec Team (forfaits).
curl sur la machine qui exécute la tâche. Il est présent sur presque tous les serveurs.

1. Créer le signal

Dans l’app web, ouvrez le projet, puis Connexions, et choisissez Nouveau signal :

Nom : ce qu’affichera le push, par exemple « Sauvegarde de nuit ».
Intervalle attendu : 5 minutes, 15 minutes, 1 heure, 1 jour, 1 semaine, ou le nombre de minutes de votre choix avec Personnalisé.
Marge : aucune, 1, 5 ou 15 minutes, ou 1 heure.
Niveau en cas de retard : un Klaxon long par défaut, ou un Klaxon continu pour les tâches les plus importantes.

Enregistrez, ouvrez Configurer et copiez l’URL du signal. Toute personne qui a cette URL peut envoyer des signaux : gardez-la comme un mot de passe. En cas de fuite, Nouvelle URL la remplace, et l’ancienne cesse aussitôt de fonctionner.

2. Envoyer un signal après chaque exécution

Ajoutez l’appel après la tâche avec &&, pour que seule une exécution réussie envoie le signal :

0 3 * * * pg_dump -f /backup/app.sql app && curl -fsS -m 10 --retry 3 https://honk-honk.app/hb/… > /dev/null

-fsS rend curl silencieux sauf en cas de problème, -m 10 abandonne au bout de 10 secondes et --retry 3 absorbe une courte coupure réseau. Si la tâche échoue, aucun signal ne part, et Honk vous prévient une fois la marge écoulée.

L’échéance se calcule à partir du dernier signal : la marge n’a donc qu’à couvrir les variations de durée de la tâche. Si la sauvegarde prend parfois 20 minutes de plus que d’habitude, prévoyez au moins cette marge.

3. Signaler un échec tout de suite

Pour une tâche de nuit, attendre l’échéance suffit. Pour être prévenu d’un échec dès qu’il se produit, appelez l’URL avec /fail quand la tâche échoue. Le texte envoyé dans le corps, jusqu’à 1 Kio, devient le message :

0 3 * * * pg_dump -f /backup/app.sql app && curl -fsS -m 10 --retry 3 https://honk-honk.app/hb/… > /dev/null || curl -fsS -m 10 --retry 3 --data-raw "pg_dump failed on $(hostname)" https://honk-honk.app/hb/…/fail > /dev/null

Honk ouvre le problème aussitôt : « Sauvegarde de nuit a signalé un échec ». Le signal de la prochaine exécution réussie le clôt, comme avant.

Si la tâche signale déjà ses échecs avec le wrapper honk-cron du guide cron, gardez-le et laissez le signal de vie vérifier seulement que la tâche s’exécute. Envoyez le signal après chaque exécution, réussie ou non, avec ; au lieu de && :

0 3 * * * /usr/local/bin/honk-cron db/backup pg_dump -f /backup/app.sql app; curl -fsS -m 10 --retry 3 https://honk-honk.app/hb/… > /dev/null

Le wrapper vous dit que la tâche a échoué, sortie comprise. Le signal de vie vous dit qu’elle n’a pas tourné du tout.

Workers, applications et systemd

Tout ce qui peut faire une requête HTTP peut envoyer des signaux : un worker de file d’attente après chaque lot, un script dans n’importe quel langage ou un service systemd. Le panneau Configurer de l’app web propose des lignes toutes prêtes pour la crontab et pour OnSuccess= et OnFailure= de systemd. Honk compte au plus un signal toutes les 10 secondes ; les appels en trop reçoivent une réponse mais sont ignorés.

Du code qui dispose déjà d’une clé d’ingestion peut passer par l’API plutôt que par l’URL. Le signal est créé à son premier appel, si bien qu’un worker peut configurer le sien tout seul :

curl -fsS -m 10 --retry 3 https://honk-honk.app/v1/heartbeats/check-in \
  -H "Authorization: Bearer $HONK_KEY" \
  -H "Content-Type: application/json" \
  -d '{"slug":"queue-worker","name":"Queue worker","interval_seconds":300,"grace_seconds":60}'

Le slug désigne le signal dans le projet de la clé. Les appels suivants peuvent modifier son nom, son intervalle et sa marge ; le niveau et la mise en pause se règlent dans l’app web. Pour signaler un échec, envoyez "status":"fail" avec un message.

Week-ends, maintenance et pauses

Honk attend un signal à intervalle fixe et ne lit pas les expressions cron. Pour une tâche qui ne tourne qu’en semaine, réglez l’intervalle sur l’écart le plus long (3 jours, du vendredi au lundi), ou ajoutez une ligne de crontab qui envoie le signal le samedi et le dimanche.

Avant une maintenance, choisissez Mettre en pause. Un signal en pause n’est pas surveillé, et la mise en pause clôt un problème ouvert. Reprendre relance le décompte à partir de ce moment. Supprimer un signal clôt aussi son problème ouvert.

Signaux de vie et alertes d’échec

Ils répondent à deux questions différentes, et une tâche importante mérite les deux :

Le guide cron vous dit que la tâche a tourné et a échoué, avec son code de retour et sa sortie.
Un signal de vie vous dit que la tâche n’a pas tourné, ou ne s’est jamais terminée, et quand elle a donné signe de vie pour la dernière fois.

Si vous avez utilisé Healthchecks.io

C’est le même principe : une URL par tâche, une période et une marge. Healthchecks.io sait aussi suivre des expressions cron et des calendriers systemd OnCalendar=, et il est open source : vous pouvez l’héberger vous-même. Honk n’a ni expressions cron ni version auto-hébergée. Ce qu’il apporte, c’est que le silence d’une tâche est signalé dans la même boîte de réception que tout ce que vous faites tourner, avec les mêmes règles de push : un push par panne, un rétablissement quand la tâche repart, des heures calmes, des Activités en direct et votre Apple Watch.

Pour l’instant, Honk est sur invitation : demandez un accès. Tout ce guide fonctionne avec le forfait Free.