Aller au contenu
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERSurveiller un service
POURFondateurs solo
POURDevOps et infra
SERVICESCron
SERVICESNotifications
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERSurveiller un service
POURFondateurs solo
POURDevOps et infra
SERVICESCron
SERVICESNotifications
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERSurveiller un service
POURFondateurs solo
POURDevOps et infra
SERVICESCron
SERVICESNotifications
POURQUOI HOODYHTTP-natif
TYPEDébloqué
ÉTAPEProduction
DIFFICULTÉSimple
MÉTIERSurveiller un service
POURFondateurs solo
POURDevOps et infra
SERVICESCron
SERVICESNotifications
POURQUOI HOODYHTTP-natif
Retour aux cas d'usage
CRON · NOTIFICATIONS · ALARME-SILENCE

Un battement de cœur pour les jobs silencieux

La plupart du monitoring surveille ce qui s'est passé. vous, vous aviez besoin de quelque chose qui surveille ce qui ne s'est pas passé. Deux entrées cron — l'une bat, l'autre écoute l'absence de battement — et la page qui vous trouve sur la plage.

Lire la doc cron

Deux entrées cron. L'une dit je suis vivant. L'autre écoute le rien.

Le job que vous avais déjà continue son travail. Une fois fini, il ajoute un curl : une ligne de heartbeat sur un endpoint de notifications. Une seconde entrée cron tourne à sa propre cadence et vérifie le silence — pas de battement frais, elle page votre téléphone. Le succès du job est silencieux. Son absence est bruyante.

worker.cron · le job
POST · heartbeat
schedule0 2 * * *
# Une fois l'export nocturne terminé,# le job ping son propre heartbeat.0 2 * * * /usr/local/bin/export.sh \ && curl -fsS -X POST \ https://notify.containers.hoody.com/heartbeats/backup-prod-db
l'absence est le signal
watcher.cron · le listener
GET · silence-check
schedule*/15 * * * *
# Toutes les 15 minutes, demande : y a-t-il eu un battement ?# Si silence > 1h, l'API page tous les canaux.*/15 * * * * curl -fsS \ https://notify.containers.hoody.com/silence-check?\ job=backup-prod-db&max_age=1h

Deux POSTs sur /users/root/entries avec des expressions à cinq champs. La première tourne après chaque job planifié et poste son heartbeat. La seconde tourne à sa propre cadence, demande à l'endpoint de notifications si le dernier battement est assez frais, et déclenche la page sinon. Pas de queue, pas d'agent, pas de daemon — juste deux lignes de crontab qui devaient déjà exister.

Pourquoi surveiller l'absence est différent

La plupart des outils de monitoring surveillent le chemin du succès : ils alertent quand quelque chose se produit. Cette forme alerte quand rien ne se produit — et c'est exactement le cas que les jobs silencieux perdent toujours.

MODES DE PANNE

Capte le crash silencieux

Si le process worker ne démarre jamais — la box a redémarré, le script a été supprimé, un quota a expiré — il n'y a rien à logger et rien sur quoi alerter. Le watcher cron tourne quand même et remarque que la ligne de heartbeat est rance. Ce qui capte le crash silencieux est exactement ce qui ne dépend pas de la chose silencieuse.

ZÉRO SURFACE

Pas de nouveau service à materner

Le moniteur est une ligne de crontab supplémentaire, pas un compte Healthchecks.io ou une alarme CloudWatch. Il est lié au même conteneur que le travail, expire avec `expires_at` si vous le veux, et lit depuis la même API de notifications que le reste de votre stack utilise déjà.

VOUS REJOINT

Bruyant quand ça compte

L'endpoint de notifications déploie la page sur push, SMS, et email — les canaux que vous utilisez déjà. vous ne surveillez pas le dashboard. Le dashboard se surveille lui-même, et vous trouve sur la plage à Bali seulement quand le silence a trop duré.

Vrai cron, vraies notifications

Le mécanisme, c'est du Hoody Cron et Hoody Notifications standard. Les chiffres viennent de la surface API documentée, pas d'un runtime de démo inventé.

  1. TOUTE SYNTAXE CRON@daily

    Expressions standard à 5 champs plus macros — `@hourly`, `@daily`, `@weekly`, `@monthly`, `@yearly`. Le watcher et le worker peuvent avoir des cadences complètement différentes.

  2. AUTO-EXPIRATIONexpires_at

    Les entrées gérées supportent `expires_at`, donc un heartbeat temporaire (une fenêtre de migration d'une semaine, par exemple) se nettoie tout seul. Le watcher disparaît avec le travail.

  3. ISOLATIONpar utilisateur

    Chaque conteneur a sa propre crontab. Le heartbeat d'un tenant ne peut pas faire taire le watcher d'un autre, et désactiver un job se fait avec un seul PATCH `enabled: false`.

Limites selon la Hoody Cron API : expressions à 5 champs plus les macros `@hourly`/`@daily`/`@weekly`/`@monthly`/`@yearly`, `expires_at` optionnel sur les entrées gérées, isolation crontab par utilisateur, activation/désactivation via PATCH.

Le silence est maintenant une alerte.

AVANT · SURVEILLER LE LOGouvrir le dashboard · chercher le dernier export · soupirer · oubliervous ne remarques le job manquant que le lundi
APRÈS · SURVEILLER LE CALME*/15 * * * * curl /silence-check?job=backup-prod-dbla page vous rejoint pendant que le silence est encore court
Lire la doc cron

Ce que ça remplace

Les outils standards qu'on attrape pour avoir un cron-monitor avec paging. Chacun est un compte séparé, une facture séparée, une API séparée. Deux lignes de crontab et l'endpoint de notifications font le même travail.

  • orchestrateurs customDes services d'orchestration entiers pour ce qui tient en deux lignes de crontab
  • Healthchecks.ioUn compte SaaS juste pour recevoir un heartbeat HTTP
  • CronitorPricing par moniteur pour ce que votre conteneur fait déjà
  • Dead Man's SnitchLe pattern exact, vendu en abonnement
  • Alarmes AWS CloudWatch pour cronLambda + alarmes + politiques IAM pour une ligne rance
  • scripts maison de collecte de heartbeatsUn microservice pour logger une valeur que le cron pourrait juste POST

Arrêtez de surveiller le chemin du succès. Surveillez l'absence de succès — c'est le seul endroit où vivent les pannes silencieuses.

Lire la doc cron

Lis les autres