Quand une tâche échoue, cron reste muet. Sa seule alerte intégrée, MAILTO, envoie par e-mail la sortie de chaque tâche qui affiche quelque chose, et vous finissez vite par ne plus lire ces e-mails. Ce que vous voulez, c’est l’inverse : le silence tant que la tâche fonctionne, et un push sur votre téléphone dès son premier échec.

Ce guide met cela en place avec la commande honk-me, en cinq minutes, pour n’importe quelle tâche : sauvegarde de base de données, script de synchronisation, commande artisan.

Avant de commencer

Un compte Honk et un projet. Honk est pour l’instant sur invitation : demandez un accès si besoin.
Une clé d’ingestion pour ce projet : dans l’app web, ouvrez le projet, puis Clés, et créez-en une. Elle se présente sous la forme honk_… et ne s’affiche qu’une fois.
La CLI honk-me sur la machine où tourne cron. C’est un simple binaire : go install github.com/honk-me/honk-go/cmd/honk-me@latest, ou téléchargez-le depuis la page des releases. Pas de CLI ? La version cURL est en fin de guide.

1. Donner la clé à cron

Cron lance les tâches avec un environnement presque vide : déclarez donc les deux variables en tête de la crontab. crontab -e ouvre un fichier lisible par votre seul utilisateur :

# crontab -e  (the file is readable by your user only)
HONK_URL=https://honk-me.app
HONK_KEY=honk_…

La CLI n’accepte volontairement pas la clé en option : elle n’apparaît ainsi jamais dans ps ni dans l’historique du shell.

2. Être alerté seulement en cas d’échec

Ajoutez || honk-me problem … après la commande. Le shell ne l’exécute que si la tâche sort en erreur, et $? contient toujours son code de sortie :

0 3 * * * pg_dump app > /backup/app.sql || honk-me problem --group-key db/backup --source "$(hostname)" --title "Backup failed" --message "pg_dump exited with $?"

C’est --group-key qui évite à votre téléphone de s’affoler. Tous les échecs de la sauvegarde arrivent dans le même groupe, db/backup. Le premier déclenche aussitôt un push. Si la tâche continue d’échouer dans le même épisode, Honk envoie au plus une mise à jour discrète toutes les 5 minutes, sans nouvelle alarme, et la boîte de réception n’affiche qu’une ligne avec un compteur.

Un piège dans lequel chacun tombe au moins une fois : dans une crontab, % signifie « retour à la ligne ». Si votre commande contient date +%F, écrivez date +\%F.

3. Être prévenu aussi quand tout repart

Un problème reste ouvert tant que rien ne le clôt. Honk le clôt quand la même clé de groupe signale un rétablissement, et vous envoie aussi un push : vous savez que vous pouvez passer à autre chose.

N’envoyez pas pour autant un rétablissement après chaque exécution réussie. Même sans problème ouvert, un rétablissement ouvre un épisode « rétabli » et déclenche une notification : vous auriez un push chaque nuit. Envoyez-le uniquement au premier succès qui suit un échec. Ce wrapper garde le dernier résultat dans un petit fichier d’état :

#!/usr/bin/env bash
# honk-cron: run a command; honk when it fails, and once when it works again.
# usage: honk-cron <group-key> <command> [args…]
set -uo pipefail
key=$1; shift
state="${XDG_STATE_HOME:-$HOME/.local/state}/honk-cron/${key//\//_}.failed"
mkdir -p "$(dirname "$state")"
out=$(mktemp); trap 'rm -f "$out"' EXIT

"$@" >"$out" 2>&1
code=$?

if [ "$code" -ne 0 ]; then
  # the end of the output is usually the useful part; a message holds up to 8192 bytes
  tail -c 6000 "$out" | honk-me problem --group-key "$key" --source "$(hostname)" \
    --title "$key failed (exit $code)" --message - || true
  touch "$state"
elif [ -e "$state" ]; then
  honk-me recovery --group-key "$key" --source "$(hostname)" \
    --title "$key works again" --message "Exit code 0 after a failure." || true
  rm -f "$state"
fi
exit "$code"

Enregistrez-le sous /usr/local/bin/honk-cron, rendez-le exécutable avec chmod +x et placez-le devant n’importe quelle tâche, la clé de groupe en premier :

0 3 * * *   /usr/local/bin/honk-cron db/backup pg_dump -f /backup/app.sql app
*/15 * * * * /usr/local/bin/honk-cron sync/invoices php /srv/app/artisan invoices:sync

Le message contient les 6 000 derniers octets de la sortie : le push et la boîte de réception montrent l’erreur réelle, pas un simple « échec ». Le wrapper renvoie toujours le code de sortie de la tâche, et || true garantit qu’un souci de notification ne fera jamais échouer une exécution réussie.

Sans la CLI : cURL

curl est installé sur presque tous les serveurs. Voici la même alerte en une ligne de crontab, JSON compris :

0 3 * * * pg_dump app > /backup/app.sql || curl -sS --max-time 10 --retry 3 "$HONK_URL/v1/messages" -H "Authorization: Bearer $HONK_KEY" -H "Content-Type: application/json" -d "{\"title\":\"Backup failed\",\"message\":\"pg_dump exited with $?\",\"severity\":\"long\",\"event_type\":\"problem\",\"group_key\":\"db/backup\"}"

La CLI ajoute ce que cette ligne ne fait pas : de nouvelles tentatives avec une seule clé d’idempotence, un délai maximal global et des codes de sortie exploitables.

Les codes de sortie

honk-me renvoie 0 si Honk a accepté l’événement (ou l’avait déjà reçu), 4 si la clé est incorrecte ou révoquée, 5 si un quota est épuisé et 7 si le réseau ou le serveur a fait défaut malgré toutes les tentatives. La page CLI les détaille tous. Dans cron, ajoutez en général || true après la commande.

Ce que Honk apporte à cron

MAILTO envoie un e-mail à chaque exécution bavarde. Honk, lui, envoie un push par nouveau problème, regroupe les répétitions avec leur sortie, vous prévient du retour à la normale et range le tout dans une seule boîte de réception, avec vos autres tâches et vos serveurs. Les heures calmes et le récapitulatif règlent le volume de vos nuits.

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