Surveillance Heartbeat

Vos crons échouent.
En silence.

Un heartbeat check est un interrupteur de sécurité pour vos tâches planifiées. Votre job envoie un ping à une URL quand il se termine. Si le ping n'arrive jamais — processus planté, serveur redémarré, job bloqué — SteadyCron vous réveille.

Démarrer gratuitement Lire la documentation

Offre gratuite — sans carte bancaire.

Sans heartbeat check

# /etc/cron.d/backup
0 2 * * * root /usr/bin/backup.sh

# Output: none.
# Exit code: who knows.
# Last successful run: unclear.
# Will anyone notice? No.

Avec un heartbeat check

# /etc/cron.d/backup
0 2 * * * root /usr/bin/backup.sh \
  && curl -fsS https://ping.steadycron.com/abc123

✓ 02:04 — ping reçu, job en bonne santé
✗ 03:02 — aucun ping — alerte #ops-slack

Le problème

Fire-and-forget n'est pas une stratégie de surveillance

Cron n'a aucune notion de succès ou d'échec. Un job s'exécute, produit une sortie que personne ne lit, et se termine — le planificateur considère sa mission accomplie quoi qu'il arrive. Le temps que vous remarquiez que quelque chose s'est mal passé, les logs ont été rotatés, la fenêtre est fermée, et les dégâts sont faits.

La sauvegarde nocturne a silencieusement échoué. Les données sont perdues.
Le job de facturation ne tourne plus depuis trois jours. C'est la finance qui s'en est aperçue.
Un script a planté et bloqué le run suivant — pendant six heures.
Le processus a été tué par OOM. Les logs ont déjà été rotatés.

Une chronologie type d'une panne cron

02:00

Job planifié

02:00

Processus démarré

02:03

Disque plein — script quitte 1

02:03

Sortie : aucune (redirigée)

03:00

Rotation des logs

09:14

L'ingénieur ouvre le tableau de bord

09:14

Aucune erreur visible nulle part

14:30

Le client signale une perte de données

12 heures entre la panne et sa découverte.

Comment ça marche

Le silence est le signal

Vous ne nous envoyez pas de données — c'est votre job qui le fait. S'il s'arrête, nous le savons.

01

Votre job envoie un ping à une URL

Après l'exécution de votre script, il appelle une URL de ping unique — rien de plus qu'un simple HTTP GET. Passez /start avant, /success après, et optionnellement /fail en cas d'erreur.

curl -fsS https://ping.steadycron.com/{id}

02

Nous ouvrons une fenêtre de grâce

SteadyCron connaît votre planning et autorise un délai de grâce configurable pour absorber la gigue normale — fenêtres de maintenance nocturne, pics de charge serveur et dérive de planning.

grace: 10m # no alert if ping arrives within 10 min

03

Le silence déclenche une alerte

Si le ping n'arrive pas avant l'expiration du délai de grâce, une alerte est envoyée à votre canal configuré — Slack, e-mail, Telegram, Discord ou webhook.

→ #ops-slack nightly-backup missed (14 h overdue)

Ce que nous détectons

Trois façons dont un job peut mal tourner

Chaque type d'échec est distinct, détectable et alerte indépendamment.

nightly-backup MISSED

Run manqué

Le job n'a jamais démarré. Le processus a été tué, le serveur a redémarré, ou le planificateur l'a sauté. Aucun ping n'est arrivé — pas même un /fail.

Attendu à 02:00 UTC

Dernier ping hier 02:04

En retard de 14 h 22 min

Détecté quand : aucun ping /start ou /success n'arrive dans la fenêtre de grâce du planning prévu.

invoice-sender FAILED

Job échoué

Le job s'est exécuté mais a quitté avec un code non nul, ou votre code a intercepté une exception et a explicitement appelé l'endpoint /fail avant de retourner.

...
$ python invoice.py
ConnectionError: DB unreachable
→ /fail ping sent
Alerted: #billing-alerts

Détecté quand : votre code appelle l'endpoint /fail, ou que le job se termine sans ping /success.

report-generator TIMED OUT

Job bloqué

Le job a démarré — /start a été reçu — mais n'a jamais envoyé /success. Il est toujours en cours, ou il est en deadlock silencieux. Un seuil de durée maximale le détecte.

/start reçu 09:00:12

Durée maximale 30 min

/success reçu jamais

Détecté quand : un /start a été reçu mais /success ou /fail n'arrive jamais dans la durée maximale configurée.

Intégration

Une ligne. N'importe quel langage.

Aucun SDK à installer, aucun agent à déployer. Un HTTP GET est l'intégration. Fonctionne depuis un script shell, une lambda Python, un binaire Go ou un Kubernetes CronJob.

# Minimal — one line at the end of your crontab command
0 2 * * * /usr/bin/backup.sh && curl -fsS https://ping.steadycron.com/abc123

# With start/fail signals (recommended)
0 2 * * * curl -fsS https://ping.steadycron.com/abc123/start \
  && /usr/bin/backup.sh \
  && curl -fsS https://ping.steadycron.com/abc123 \
  || curl -fsS https://ping.steadycron.com/abc123/fail

import requests, subprocess, sys

PING = "https://ping.steadycron.com/abc123"

requests.get(f"{PING}/start", timeout=5)
result = subprocess.run(["/usr/bin/backup.sh"])

if result.returncode == 0:
    requests.get(PING, timeout=5)
else:
    requests.get(f"{PING}/fail", timeout=5)
    sys.exit(result.returncode)

const PING = "https://ping.steadycron.com/abc123";

await fetch(`${PING}/start`);
try {
  await runMyJob();
  await fetch(PING);             // success
} catch (err) {
  await fetch(`${PING}/fail`);   // explicit failure
  throw err;
}

const ping = "https://ping.steadycron.com/abc123"

http.Get(ping + "/start")

if err := runMyJob(); err != nil {
    http.Get(ping + "/fail")
    log.Fatal(err)
}

http.Get(ping) // success

require "net/http"
PING = "https://ping.steadycron.com/abc123"

Net::HTTP.get(URI("#{PING}/start"))
begin
  run_my_job
  Net::HTTP.get(URI(PING))          # success
rescue => e
  Net::HTTP.get(URI("#{PING}/fail"))
  raise
end

https://ping.steadycron.com/abc123";

file_get_contents(PING . "/start");
try {
    run_my_job();
    file_get_contents(PING);          // success
} catch (\Throwable $e) {
    file_get_contents(PING . "/fail");
    throw $e;
}

L’URL de ping est générée lorsque vous créez le check — copiez-la dans votre script. Vous préférez définir les monitors en code ? Déclarez-les en YAML ou Terraform.

Alertes intelligentes · Délais de grâce

Tout retard n'est pas une panne

Les plannings sont des objectifs. La charge serveur, les fenêtres de maintenance nocturne et les secondes intercalaires décalent les jobs de quelques minutes après leur heure planifiée. Un délai de grâce absorbe cette gigue normale pour que vous ne soyez alerté que quand quelque chose ne va vraiment pas.

Définissez-le par check — un ping de santé rapide de 5 minutes peut utiliser une grâce de 2 minutes ; un ETL nocturne lourd qui prend parfois 20 minutes peut en utiliser 30.

Délai de grâce en action

02:00

Ping attendu

02:06

Ping reçu (6 min en retard)

dans la grâce de 10 min — pas d'alerte

03:00

Ping attendu

03:11

Aucun ping (11 min en retard)

grâce expirée — alerte envoyée

grace: 600 # seconds — 10 minutes

Alertes intelligentes · Réduction du bruit

Conçu pour réduire le bruit, pas l'augmenter

La fatigue aux alertes est réelle. SteadyCron dispose de plusieurs mécanismes pour garder votre pager silencieux sauf si quelque chose nécessite genuinement votre attention.

Seuil d'échecs consécutifs

Un simple raté — une micro-coupure réseau, un OOM kill ponctuel — ne devrait pas réveiller votre équipe à 3h du matin. Définissez un seuil de N échecs consécutifs avant qu'une alerte se déclenche. Le premier échec est journalisé ; le troisième déclenche l'alerte.


alert_after: 3 # alerter seulement après 3 manques consécutifs

Garde anti-oscillation

Un job qui alterne rapidement entre sain et en échec génère une tempête d'alertes sans signal utile. Le garde anti-oscillation détecte cette alternance et supprime les notifications répétées jusqu'à ce que le job se stabilise — une alerte, pas vingt.

 # fail → ok → fail → ok → fail
 ⚠ oscillation détectée — alerte retenue

Heures calmes

Définissez une fenêtre temporelle par check où les échecs non critiques sont supprimés — l'alerte est journalisée mais non délivrée. Quand votre équipe est de retour en ligne, tout ce qui s'est passé se trouve dans le journal de livraison avec sa raison de suppression.


quiet_hours: "22:00–07:00 Europe/Berlin"

Cycle de vie d'une alerte

🔴

nightly-backup manqué

02:14 — alerte envoyée à #ops-slack

📋

Alerte supprimée (heures calmes)

03:00 — manque suivant journalisé, non envoyé

✅

nightly-backup récupéré

02:07 le lendemain — résolu automatiquement

🔕

#ops-slack notifié : résolu

Aucun accusé de réception manuel nécessaire

Alertes intelligentes · Résolution automatique

Les alertes se résolvent d'elles-mêmes

Quand un job récupère — le prochain ping arrive avec succès — SteadyCron résout automatiquement l'alerte ouverte et envoie une notification de résolution au même canal. Vous n'avez jamais à fermer manuellement un incident qui s'est déjà résolu.

Chaque événement d'alerte est journalisé avec son déclencheur, son canal de livraison, son statut et sa raison de suppression le cas échéant — vous avez ainsi toujours un enregistrement complet de ce qui s'est déclenché, ce qui a été retenu, et pourquoi.

Une plateforme, trois métiers

Exécution HTTP

Appelez vos endpoints à l’heure prévue — réessais, délais et journaux complets.

Surveillance heartbeat

Vous êtes ici

Surveillez les tâches que vous exécutez partout ; soyez alerté dès qu’une se tait.

Cron as code

Déclarez chaque tâche, moniteur et alerte en YAML ou Terraform.

Vos jobs devraient vous dire qu'ils ont tourné.

Ajoutez un heartbeat check en deux minutes. Aucun agent, aucun SDK, aucun changement d'infrastructure — juste une URL à la fin de votre script.

Démarrer gratuitement Lire la documentation

Offre gratuite — sans carte bancaire
Hébergé en UE, RGPD natif
Tout langage, toute plateforme