Monitoring cron
sans tâche oubliée.
Monitoring par heartbeat pour vos sauvegardes, vos rapports et chaque tâche planifiée. Chaque tâche appelle sa propre URL quand elle se termine, et votre équipe est alertée quand une exécution manque.
Inclus dans tous les forfaits, Free compris. Sans carte bancaire.
Choisi par les équipes pour qui la disponibilité passe avant tout.
Lire les témoignages clients
Six façons dont une tâche cron échoue en silence. Chacune manque son ping.
Le monitoring des tâches cron transforme le silence en alerte. Chaque tâche envoie un ping à Hyperping quand elle s’exécute, et un ping qui n’arrive pas à l’heure est traité comme une panne. Il repère ce que les logs ne voient pas : une tâche qui n’a jamais démarré n’écrit aucune erreur.
- 0 2 * * * · rebooted at 01:58no ping by 02:30 · alert
La tâche qui n’a jamais démarré
Un redémarrage, un conteneur qui n’est pas revenu, une crontab perdue lors d’un redéploiement. Rien ne tourne, donc rien ne journalise d’erreur. Le ping manquant est la seule trace, et elle suffit.
Fonctionnement des healthchecks - backup.sh · exit 1&& curl skipped · alert
La tâche qui a planté
Enchaînez le ping après la commande avec &&, et une exécution qui se termine en erreur n’envoie jamais de ping. Hyperping vous alerte dès la fin du délai de grâce.
Pinguer seulement en cas de succès - /start 02:00 · no end pingdeadline passed · alert
La tâche qui reste bloquée
Un verrou jamais libéré, une requête coincée sur une table. Appelez /start au démarrage de la tâche et l’URL à la fin : la durée de chaque exécution est enregistrée, et une exécution qui ne se termine jamais manque son échéance.
Mesurer la durée d’exécution - 0 2 * * * · read as UTCcron mode · Europe/Paris
Le planning dans le mauvais fuseau horaire
Donnez au healthcheck l’expression cron et le fuseau horaire de la tâche. L’échéance suit le changement d’heure avec elle : une tâche qui tourne à 2 h à Paris est attendue à 2 h à Paris.
Générateur d’expressions cron - worker · last ping 47 min agoevery 15 min · alert
Le worker qui s’est arrêté sans bruit
Un consommateur de file, une boucle de synchronisation, un scheduler Laravel ou Rails. Tout ce qui tourne en boucle peut envoyer un ping à chaque passage, et le mode simple alerte quand les pings cessent d’arriver.
Mode simple - GitHub Actions · schedule offno ping · alert
Le workflow planifié désactivé sans que personne ne le voie
GitHub désactive les workflows planifiés des dépôts publics après 60 jours sans activité, et un runner de CI peut rester en file d’attente. Un ping en dernière étape du workflow vous dit quand il a cessé de tourner.
Exemple GitHub Actions
Une URL par tâche. Une ligne dans votre crontab.
Ni agent ni SDK. Un healthcheck est une URL que votre tâche appelle, et Hyperping surveille l’horloge.
- 1
Créez un healthcheck
Donnez-lui le nom de la tâche et son planning : un intervalle, ou la même expression cron avec son fuseau horaire. Ajoutez un délai de grâce un peu plus long qu’une exécution normale.
- 2
Pinguez son URL quand la tâche se termine
Une requête HEAD, GET ou POST depuis n’importe quel outil qui parle HTTP. Dans une crontab, enchaînez-la avec
&&pour que seule une exécution réussie envoie le ping. Ajoutez/startau démarrage pour enregistrer la durée de chaque exécution. - 3
Soyez alerté quand une exécution manque
Pas de ping à l’heure prévue plus le délai de grâce, et le healthcheck passe en panne : un incident s’ouvre et vos canaux sont alertés en quelques secondes. Le ping suivant le clôt et envoie un rétablissement.
# Back up at 2:00 every night, ping Hyperping only if it succeeds
0 2 * * * /usr/local/bin/backup.sh && curl -fsS --retry 3 https://hc.hyperping.io/tok_8f3kq2Lm9xV4#!/bin/sh
set -e
# The run starts: its duration is measured from here
curl -fsS --retry 3 https://hc.hyperping.io/tok_8f3kq2Lm9xV4/start
pg_dump "$DATABASE_URL" | gzip > /backups/db-$(date +%F).sql.gz
# The run ends: Hyperping logs the duration and the next deadline
curl -fsS --retry 3 https://hc.hyperping.io/tok_8f3kq2Lm9xV4await sendInvoices();
// Ping at the end of the job
await fetch("https://hc.hyperping.io/tok_8f3kq2Lm9xV4");import requests
build_report()
# Ping at the end of the job
requests.get("https://hc.hyperping.io/tok_8f3kq2Lm9xV4", timeout=10)use Illuminate\Support\Facades\Schedule;
// Laravel pings /start before the run, and the URL only if it succeeds
Schedule::command("backup:run")
->dailyAt("02:00")
->timezone("Europe/Paris")
->pingBefore("https://hc.hyperping.io/tok_8f3kq2Lm9xV4/start")
->pingOnSuccess("https://hc.hyperping.io/tok_8f3kq2Lm9xV4");func main() {
if err := syncInventory(); err != nil {
// No ping: Hyperping alerts once the grace period runs out
log.Fatal(err)
}
// Ping at the end of the job
client := http.Client{Timeout: 10 * time.Second}
if _, err := client.Get("https://hc.hyperping.io/tok_8f3kq2Lm9xV4"); err != nil {
log.Printf("ping failed: %v", err)
}
}on:
schedule:
- cron: "0 2 * * *"
jobs:
backup:
runs-on: ubuntu-latest
steps:
- run: ./backup.sh
- run: curl -fsS --retry 3 https://hc.hyperping.io/tok_8f3kq2Lm9xV4apiVersion: batch/v1
kind: CronJob
metadata:
name: nightly-report
spec:
schedule: "0 6 * * *"
timeZone: "Europe/Paris"
jobTemplate:
spec:
template:
spec:
restartPolicy: Never
containers:
- name: report
image: ghcr.io/acme/report:latest
command: ["/bin/sh", "-c"]
args: ["./report.sh && curl -fsS https://hc.hyperping.io/tok_8f3kq2Lm9xV4"]# Started every night by backup.timer (OnCalendar=*-*-* 02:00:00)
[Unit]
Description=Nightly database backup
[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh
# Runs only if ExecStart exited with success
ExecStartPost=/usr/bin/curl -fsS --retry 3 https://hc.hyperping.io/tok_8f3kq2Lm9xV4# Run the job's container, ping only if it exits with code 0
0 2 * * * docker run --rm --env-file /etc/backup.env ghcr.io/acme/backup:latest && curl -fsS --retry 3 https://hc.hyperping.io/tok_8f3kq2Lm9xV4
# Same with a Compose service
0 3 * * * cd /srv/app && docker compose run --rm report && curl -fsS --retry 3 https://hc.hyperping.io/tok_8f3kq2Lm9xV4# Windows Task Scheduler action: powershell.exe -File C:\jobs\export-orders.ps1
& C:\jobs\export-orders.exe
if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }
# Ping at the end of the job
Invoke-RestMethod -Uri "https://hc.hyperping.io/tok_8f3kq2Lm9xV4" -TimeoutSec 10Simple ou cron. Dans le fuseau horaire de la tâche.
Un healthcheck sait quand la prochaine exécution est due : il alerte sur l’exécution qui n’a pas eu lieu, pas des heures plus tard quand quelqu’un s’en aperçoit.
- 1
Mode simple, pour les boucles et les workers
Attendez un ping toutes les X minutes, heures ou jours, à partir d’une minute. Le compteur repart à chaque ping, ce qui convient aux workers et aux synchros qui tournent en boucle.
- 2
Mode cron, pour les tâches planifiées
Collez l’expression à cinq champs de la tâche et choisissez son fuseau horaire. Chaque exécution est attendue au moment où cron la lancerait, week-ends et changements d’heure compris. Pas sûr de la syntaxe ? Utilisez le générateur d’expressions cron.
- 3
Un délai de grâce pour les exécutions lentes
Le temps d’attente après l’heure prévue avant d’alerter, 10 minutes sauf si vous le changez. Une sauvegarde qui prend d’habitude 4 minutes peut en avoir 30 : une nuit plus lente ne réveille personne.
- Mode
- Simple
- Every
- 15 minutes
- Grace period
- 5 minutes
- Last ping
- Oct 6, 09:14:58
- Down if no ping by
- Oct 6, 09:34:58
- Oct 6, 09:29:58 · next ping expected
- Oct 6, 09:34:58 · end of grace period
En mode simple, le compteur repart à chaque ping : 15 minutes jusqu’au suivant, plus 5 minutes de délai de grâce. Un worker qui ne pingue plus est signalé 20 minutes après son dernier passage.
- Mode
- Cron
- Expression
- 0 2 * * *
- Timezone
- Europe/Paris
- Grace period
- 30 minutes
- Down if no ping by
- Oct 7, 02:30 CEST
- Wed, Oct 7 · 02:00 CEST
- Thu, Oct 8 · 02:00 CEST
- Fri, Oct 9 · 02:00 CEST
En mode cron, l’échéance suit l’expression, pas le dernier ping. Une sauvegarde qui pingue à 02:04 ce soir reste attendue à 02:00 demain, avec 30 minutes de délai de grâce.
- Mode
- Cron
- Expression
- 0 9 * * 1-5
- Timezone
- America/New_York
- Grace period
- 15 minutes
- Down if no ping by
- Nov 2, 09:15 EST
- Mon, Nov 2 · 09:00 EST
- Tue, Nov 3 · 09:00 EST
- Wed, Nov 4 · 09:00 EST
Le rapport du vendredi a pingé à 09:02. Rien n’est attendu le week-end, donc rien n’alerte, et le changement d’heure du 1er novembre ne décale pas l’exécution du lundi : le fuseau horaire fait le calcul.
- Mode
- Cron
- Expression
- 0 0 1 * *
- Timezone
- UTC
- Grace period
- 2 hours
- Down if no ping by
- Nov 1, 02:00 UTC
- Sun, Nov 1 · 00:00 UTC
- Tue, Dec 1 · 00:00 UTC
- Fri, Jan 1 · 00:00 UTC
Une tâche mensuelle, c’est celle qu’on oublie pendant des semaines. Un délai de grâce de deux heures laisse de la marge à une exécution lente et déclenche quand même l’alerte bien avant que quelqu’un ne réclame les factures.
Une exécution manquée est un incident. Votre équipe l’apprend la première.
Les healthchecks sont comparés à leur échéance toutes les quelques secondes : l’alerte part dès la fin du délai de grâce, et l’incident figure dans la même liste que vos autres moniteurs.
- En lignepinged on schedule
La dernière exécution a pingé à temps. La prochaine échéance découle du planning : le prochain ping en mode simple, la prochaine exécution cron en mode cron.
- Délai de grâcedue, no ping yet
L’exécution est attendue et n’a pas encore appelé l’URL. Le healthcheck reste en ligne et rien n’est envoyé avant la fin du délai de grâce, donc une tâche qui dure quelques minutes de plus ne déclenche rien.
- En pannemissed its scheduled ping
Le délai de grâce est écoulé. Un incident s’ouvre, tous les canaux sont alertés en même temps, et le healthcheck reste en panne jusqu’au prochain ping de la tâche : une alerte par exécution manquée, pas une par minute.
- Rétabliback on schedule
Le ping suivant résout l’incident et envoie un rétablissement sur les mêmes canaux. Les alertes PagerDuty et Opsgenie se ferment d’elles-mêmes.
Là où travaille votre équipe.Partout à la fois, dès le premier retard.
L’e-mail et le SMS touchent chaque membre du projet, Slack, Discord et Telegram les canaux que vous avez connectés. Envoyez-la à PagerDuty ou Opsgenie pour alerter la personne d’astreinte chez eux.
Slack
PagerDuty
Opsgenie
Discord
Telegram- SMS
À côté de vos vérifications de disponibilité. Sur la même page de statut.
Les healthchecks vivent dans le même compte que vos moniteurs, vos incidents et vos pages de statut : un import manqué et une API lente sont à un clic l’un de l’autre.
- Oct 06 02:48:21 · OK · 4m 09slast 20 pings kept
Chaque exécution, enregistrée
Chaque ping enregistre son heure, l’adresse IP, la méthode et le user agent, et la durée de l’exécution quand elle a commencé par /start. Un graphique sur 24 heures montre les exécutions heure par heure.
Historique des pings - Nightly database backup · 99.93%uptime bars · status page
Sur votre page de statut
Ajoutez un healthcheck à une page de statut, à côté de vos sites et de vos API. Vos clients voient l’import, la synchro ou le rapport comme un service de plus, en ligne ou en panne, avec sa disponibilité.
Pages de statut - 30 days · uptime · CSVweekly report email
Dans vos rapports
La disponibilité d’un healthcheck est calculée à partir de ses pannes, sur 30 jours par défaut, exportable en CSV et incluse dans le rapport hebdomadaire à côté de vos moniteurs.
Reporting
Les healthchecks en code. Depuis l’API, Terraform ou votre agent IA.
- 1
Créez-les depuis l’API
Envoyez en POST un name, une expression cron et son timezone, ou period_value et period_type, plus le délai de grâce. La réponse contient l’URL de ping à donner à votre tâche.
- 2
Ou déclarez-les dans Terraform
La ressource hyperping_healthcheck garde le healthcheck de chaque tâche à côté de l’infrastructure qui l’exécute, et expose son URL de ping comme valeur sensible.
- 3
Demandez à votre agent IA si la sauvegarde a tourné
Le serveur MCP liste vos healthchecks avec leur état, leur dernier ping et leur prochaine échéance : Claude, Cursor ou un autre agent peut répondre à « les tâches de cette nuit ont-elles tourné ? ».
curl -X POST https://api.hyperping.io/v2/healthchecks \
-H "Authorization: Bearer $API_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"name": "Nightly database backup",
"cron": "0 2 * * *",
"timezone": "Europe/Paris",
"grace_period_value": 30,
"grace_period_type": "minutes"
}'resource "hyperping_healthcheck" "nightly_backup" {
name = "Nightly database backup"
cron = "0 2 * * *"
timezone = "Europe/Paris"
grace_period_value = 30
grace_period_type = "minutes"
}
output "backup_ping_url" {
value = hyperping_healthcheck.nightly_backup.ping_url
sensitive = true
}{
"uuid": "hc_Kq3vX9mPzL2wR8tY5nB7cD4f",
"name": "Nightly database backup",
"state": "up",
"last_ping_at": "2026-10-06T00:04:12.000Z",
"next_ping_due_at": "2026-10-07T00:00:00.000Z",
"down_if_no_ping_by": "2026-10-07T00:30:00.000Z",
"schedule": "cron '0 2 * * *' (Europe/Paris)",
"grace": "30 minutes"
}Un guide pour votre planificateur. Où placer le ping, et comment il échoue.
Chaque planificateur cache ses échecs à sa façon. Chaque guide est une configuration testée : ce qui casse, comment le voir avec les outils du planificateur, et le healthcheck qui détecte l’exécution manquée. Guides en anglais.
Serveurs et plateformes
- Timers systemdPersistent=true, fuseaux horaires, un ping seulement en cas de succès.
- Planificateur de tâches WindowsUne tâche en échec qui affiche un succès.
- CronJobs KubernetesExécutions manquées et pods bloqués en Pending.
- Workflows planifiés GitHub ActionsExécutions en retard et désactivation au bout de 60 jours.
- Cron jobs VercelPas de nouvelle tentative, redirections et délais dépassés.
- Cron Triggers Cloudflare WorkerswaitUntil, et 1 veut dire dimanche.
Frameworks et files d’attente
- Scheduler LaravelpingOnSuccess ou thenPing, et schedule:run.
- Jobs planifiés RailsSolid Queue, GoodJob et whenever.
- Cron jobs Node.jsnode-cron, BullMQ et Agenda.
- Celery beatUn beat qui publie sans aucun worker.
- Cron jobs SidekiqDes retries qui masquent l’échec.
- pg_cronDes jobs qui s’arrêtent après un redémarrage ou un failover.
Les jobs qui ne doivent pas échouer en silence
Comparer
- Hyperping vs CronitorUn forfait au lieu d’un prix par moniteur et par utilisateur.
- Hyperping vs Healthchecks.ioLes mêmes URL de ping, à côté de la disponibilité et des pages de statut.
- Hyperping vs Sentry CronsPas de supplément par moniteur cron en plus d’un forfait.
- Hyperping vs Dead Man’s SnitchDes expressions cron dans le fuseau horaire de chaque job.
Un service qui doit toujours répondre ? C’est du monitoring de disponibilité.
Les healthchecks attendent que vos tâches les appellent. Les moniteurs de disponibilité appellent vos sites et vos API jusqu’à toutes les 30 secondes, depuis 17 régions maximum. La plupart des équipes utilisent les deux, avec le même forfait.
Ce que coûtent 50 ou 500 tâches. Forfaits gratuits compris.
Si vous ne surveillez que des tâches cron, Healthchecks.io coûte moins cher. Hyperping vaut le coup quand le même forfait surveille aussi vos sites et vos API et fait tourner votre status page : les healthchecks comptent dans les moniteurs du forfait, rien n’est facturé par tâche, et Essentials inclut 3 sièges.
| Prix mensuelUSD, facturation mensuelle, un utilisateur | HyperpingLes healthchecks comptent comme moniteurs | Healthchecks.ioMonitoring cron, open source | CronitorFacturé par moniteur et par utilisateur |
|---|---|---|---|
| Forfait gratuit | 20 tâchesPartagées avec les moniteurs de disponibilité | 20 tâchesHobbyist | 5 tâchesHacker, 1 utilisateur |
| 50 tâches | $29Essentials, 24 $ en annuel | $20Business, jusqu’à 100 tâches | $10550 × 2 $, plus 5 $ par utilisateur |
| 500 tâches | $299Business, 249 $ en annuel | $80Business Plus, jusqu’à 1 000 tâches | $1,005500 × 2 $, plus 5 $ par utilisateur |
| Aussi dans le prix | Moniteurs de disponibilité, status pages, astreinte pour les moniteursDans le même nombre de moniteurs | Monitoring cron uniquementOpen source, gratuit en auto-hébergement | Checks de disponibilité, status pageFacturés au moniteur eux aussi |
Prix vérifiés le 8 octobre 2026 sur la page tarifs de chaque éditeur. Tous les outils et leurs limites, côte à côte : les meilleurs outils de monitoring cron (en anglais).
Ce que les équipes disent de Hyperping.
@hyperping est vraiment incroyable
Chez nous, Hyperping a la réputation d’être plus réactif que Datadog. Nous recevons généralement les notifications de Hyperping avant celles de Datadog.
Nous avons choisi Hyperping pour offrir à nos utilisateurs un tableau de bord de grande qualité sur nos incidents et l’état de nos services.
Les alertes en temps réel de Hyperping nous signalent quand l’application est en panne. Elles arrivent parfois avant même qu’AWS ne s’en rende compte ou ne nous prévienne.
Aujourd’hui, nous ne pourrions plus imaginer faire tourner notre SaaS sans Hyperping.
Hyperping excelle sur tous les plans : une mise en place fluide, la tranquillité d’esprit et un service client attentif.
Questions sur le monitoring des tâches cron.
Qu’est-ce que le monitoring des tâches cron ?
Le monitoring des tâches cron vérifie que les tâches planifiées s’exécutent vraiment. Chaque tâche envoie un ping à une URL unique quand elle se termine, et le service de monitoring vous alerte quand un ping n’arrive pas à l’heure prévue. Il repère ce que les logs ne voient pas : une tâche qui n’a jamais démarré n’écrit aucune erreur. Chez Hyperping, ces moniteurs s’appellent des healthchecks.
Comment surveiller une tâche cron ?
Créez un healthcheck avec le planning de la tâche, sous forme d’intervalle ou de son expression cron avec son fuseau horaire, et un délai de grâce. Copiez son URL de ping et ajoutez une requête à la fin de la tâche, par exemple && curl -fsS suivi de l’URL dans votre crontab. Si le ping n’est pas arrivé à l’heure prévue plus le délai de grâce, Hyperping vous alerte.
Qu’est-ce que le heartbeat monitoring, ou dead man’s switch ?
La même idée sous d’autres noms. Au lieu d’un moniteur qui vérifie votre service, c’est votre tâche qui envoie un signal, le heartbeat, à chaque exécution, et l’alerte se déclenche quand le signal s’arrête. C’est idéal pour tout ce qui n’a pas d’URL à vérifier : tâches cron, sauvegardes, workers de file, pipelines ETL et workflows de CI planifiés.
Vous venez des heartbeats d’Opsgenie ?
Opsgenie ferme le 5 avril 2027, heartbeats compris. Chaque heartbeat devient un healthcheck avec le même intervalle, et son URL de ping remplace le ping Opsgenie dans votre tâche. Une différence : une exécution manquée alerte tous les canaux en même temps au lieu de passer par votre planning d’astreinte. Si quelqu’un doit être réveillé, envoyez les alertes des healthchecks vers PagerDuty. Le guide de migration depuis Opsgenie fournit un script qui les recrée tous.
Comment savoir si une tâche cron a échoué ?
N’envoyez le ping que si la tâche réussit : dans un shell, enchaînez la requête après la commande avec &&, et dans votre code, appelez l’URL une fois le travail terminé. Une tâche qui plante, se termine en erreur ou ne démarre jamais n’envoie alors rien, et Hyperping vous alerte une fois le délai de grâce écoulé. Hyperping ne stocke ni le code de sortie ni la sortie de la tâche : gardez vos logs pour comprendre pourquoi.
Qu’est-ce qu’un délai de grâce dans le monitoring cron ?
C’est le temps qu’Hyperping attend après l’heure d’exécution prévue avant d’alerter. Une sauvegarde planifiée à 2 h avec un délai de grâce de 30 minutes peut pinguer jusqu’à 2 h 30. Réglez-le un peu au-dessus de la durée habituelle de la tâche pour que les exécutions lentes ne réveillent personne. Il commence à 1 minute et vaut 10 minutes par défaut dans le dashboard.
Hyperping comprend-il les expressions cron et les fuseaux horaires ?
Oui. En mode cron, donnez au healthcheck l’expression à cinq champs de la tâche, par exemple 0 9 * * 1-5, et son fuseau horaire, par exemple America/New_York. Hyperping en déduit chaque exécution attendue : les week-ends sans exécution n’alertent pas et les changements d’heure sont pris en compte. Construisez ou vérifiez une expression avec le générateur d’expressions cron.
Puis-je voir combien de temps durent mes tâches cron ?
Oui. Appelez l’URL suivie de /start au démarrage de la tâche, et l’URL seule à la fin. L’historique du healthcheck affiche la durée de chaque exécution, ainsi que l’heure, l’adresse IP, la méthode et le user agent de chaque ping. Une exécution qui démarre sans jamais se terminer manque son échéance et alerte comme une exécution manquée.
Puis-je surveiller des CronJobs Kubernetes, des GitHub Actions ou des tâches planifiées Windows ?
Oui. Tout ce qui sait faire une requête HTTP peut pinguer un healthcheck : curl ou wget dans une crontab, un timer systemd ou un CronJob Kubernetes, une étape à la fin d’un workflow GitHub Actions ou GitLab CI, Invoke-WebRequest dans une tâche planifiée Windows, ou une requête depuis votre code dans un scheduler Laravel, Rails, Django ou Node.js.
Quelle différence entre monitoring des tâches cron et monitoring de disponibilité ?
Le monitoring de disponibilité vérifie un service depuis l’extérieur : Hyperping appelle votre site ou votre API jusqu’à toutes les 30 secondes et alerte quand il ne répond plus. Le monitoring des tâches cron fonctionne dans l’autre sens : c’est votre tâche qui appelle Hyperping, et le silence signale la panne. La plupart des équipes ont besoin des deux, et Hyperping les fait tourner côte à côte. Voir le monitoring de disponibilité.
Le monitoring des tâches cron est-il gratuit ?
Les healthchecks sont inclus dans tous les forfaits, Free compris. Chaque healthcheck compte comme un des moniteurs du forfait : 20 sur Free, 50 sur Essentials, 250 sur Pro et 1 000 sur Business, partagés avec vos vérifications de disponibilité. Voir les tarifs.
Comment Hyperping se compare-t-il à Cronitor ou Healthchecks.io ?
Cronitor va plus loin dans l’analyse des tâches et Healthchecks.io est open source et gratuit en auto-hébergement. Hyperping réunit le monitoring cron, les vérifications de disponibilité, les pages de statut et les incidents dans un seul compte. Voir Hyperping vs Cronitor et Hyperping vs Healthchecks.io, ou tous les outils côte à côte dans les meilleurs outils de monitoring des tâches cron.