Cron ne signale pas les échecs. Un job plante, le planning continue, et vous l'apprenez des jours plus tard par un client. Cronitorex attend un ping de chaque exécution et vous alerte en 60 secondes quand l'un d'eux n'arrive pas.
Chaque exécution signale run au démarrage, puis complete ou fail à la fin. Deux appels supplémentaires dans votre crontab suffisent. Pas d'agent, pas de daemon, aucune bibliothèque à installer.
À partir de ces pings, Cronitorex construit une chronologie par job : durées, codes de sortie, historique des échecs. Une exécution qui démarre et ne se termine jamais compte aussi comme un échec.
*/5 * * * * root cronitorex ping db-backup run; /opt/backup.sh && cronitorex ping db-backup complete || cronitorex ping db-backup fail
Un serveur planté n'envoie pas de ping fail. Cronitorex connaît l'intervalle attendu de chaque job et attend une période de grâce supplémentaire pour absorber les variations normales. Quand cette fenêtre se referme sans ping, vous recevez une alerte d'exécution manquée.
Les deux valeurs sont à vous de définir par monitor. Une sauvegarde nocturne avec 15 minutes de grâce se comporte différemment d'un job de synchronisation qui tourne toutes les 5 minutes avec 60 secondes de grâce.
Le client cronitorex.sh encapsule votre commande : il envoie run, exécute le job, mesure la durée, capture le code de sortie et les dernières lignes de stderr, puis termine avec complete ou fail. Vous changez un mot dans le crontab, pas votre script.
Vous avez déjà un crontab complet ? La commande discover le lit et crée un monitor pour chaque job trouvé, avec le planning repris directement de l'expression cron.
# encapsuler n'importe quel job : code de sortie, durée et stderr capturés cronitorex.sh run db-backup -- /opt/backup.sh # importer votre crontab existant comme monitors cronitorex.sh discover /etc/crontab
Oui. Tout ce qui peut envoyer une requête HTTP peut envoyer un ping : timers systemd, CronJobs Kubernetes, tâches Airflow, GitHub Actions, planificateur de tâches Windows. Cronitorex ne voit que les pings, pas le planificateur derrière.
Chaque ping est un événement : run, complete, fail ou skip. Un job qui envoie run et complete une fois par heure produit environ 1 440 événements par mois, donc les 50 000 événements du plan Free couvrent des dizaines de jobs.
L'API commence à renvoyer HTTP 402 et les nouveaux pings ne sont plus acceptés jusqu'à la réinitialisation mensuelle ou une mise à niveau. Rien n'est supprimé ; le dashboard et votre historique restent disponibles en permanence.
Inscrivez-vous, récupérez une clé API, collez le curl dans votre cron. C'est tout.