Le mode de défaillance dont personne ne parle : une tâche planifiée cesse de fonctionner et personne ne vous le dit. Windows Task Scheduler affiche un statut vert « Prêt » tandis que le script sous-jacent quitte silencieusement en raison d’une dépendance manquante depuis trois semaines. Un travail cron sur le serveur domestique survit à une mise à niveau du système d’exploitation dans le calendrier mais pas dans l’environnement, et la sauvegarde censée s’exécuter chaque nuit cesse d’écrire des fichiers. Le système ne pense pas que quelque chose ne va pas parce que rien n’a été levé. La sauvegarde a simplement disparu.
Nous avons testé 7 meilleures applications pour détecter les défaillances silencieuses des tâches planifiées sur Linux, Windows et macOS en 2026. La liste couvre les services dead-man-switch qui attendent un ping de votre travail et alertent quand il devient silencieux, les moniteurs de disponibilité généraux qui gèrent également les pulsations en mode push, les exportateurs de métriques qui vous permettent de représenter graphiquement le motif, et les outils locaux qui transforment le signal brut en une alerte où vous la lisez réellement.
Quoi rechercher dans un moniteur de tâches planifiées
Choisissez un outil qui :
- Utilise un dead-man switch, pas seulement « vérifier que le code de sortie était zéro ». Le point c’est que le travail n’est pas en cours d’exécution du tout.
- Gère la tolérance d’horaire de manière sensée. Un travail qui s’exécute à 03:00 devrait tolérer quelques minutes de dérive avant d’alerter ; un travail qui s’exécute toutes les minutes ne devrait pas tolérer des heures.
- Envoie les alertes à un canal que vous vérifiez. Le courrier électronique est bien jusqu’à ce que la panne soit sur votre serveur de courrier ; superposez au moins un canal non-email (un service push, un webhook Discord, un SMS).
- S’exécute indépendamment de l’hôte qu’il surveille. Un moniteur qui meurt avec la boîte qu’il regarde n’est pas un moniteur.
- Ne nécessite pas de paiement par travail. Les ménages ont souvent vingt ou trente tâches planifiées ; un modèle de facturation par travail transforme l’infrastructure domestique en centre de coûts d’entreprise.
Comparaison rapide
| Application | Meilleur pour | Approche | Auto-hébergée | Niveau gratuit |
|---|---|---|---|---|
| Healthchecks.io | Dead-man switch avec option auto-hébergée | Push heartbeat | Oui | Oui, 20 vérifications |
| Cronitor | Télémétrie cron complète avec statistiques par travail | Push + wrapper | Non | Oui, 5 moniteurs |
| Dead Man’s Snitch | Le service de pulsation de tâche planifiée original | Push heartbeat | Non | Oui, 1 snitch |
| Uptime Kuma | Moniteur de disponibilité auto-hébergé avec mode push | Pull + push | Oui | Gratuit, auto-hébergé |
| Prometheus Node Exporter | Métriques pour l’état du timer systemd | Pull métriques | Oui | Gratuit |
| systemd | Détection native des défaillances sur Linux | Natif | Oui | Gratuit |
| Gotify | Serveur de notifications push auto-hébergé | Push server | Oui | Gratuit |
Pourquoi « la tâche a fonctionné » n’est pas la même chose que « la tâche a réussi »
Le modèle mental utilisé par la plupart des planificateurs est « le processus a-t-il terminé ? » et le modèle mental nécessaire est « le résultat a-t-il eu lieu ? » Un script de sauvegarde qui s’est terminé avec succès parce que le répertoire source était vide n’est pas une sauvegarde qui fonctionne. Une synchronisation qui s’est terminée avec succès parce que le réseau était hors ligne et la boucle de nouvelle tentative s’est arrêtée silencieusement n’est pas une synchronisation qui fonctionne. Une tâche rebuild-search-index qui s’est terminée avec succès parce que le démon était inactif et le client a renvoyé une réponse vide n’est pas une reconstruction qui fonctionne.
La correction est sur deux niveaux : le travail envoie une pulsation uniquement après avoir complété son travail réel (pas seulement après son lancement), et le moniteur alerte quand la pulsation disparaît. Rien d’autre dans la pile d’horaire ne détecte le mode « faire silencieusement rien ». Task Scheduler ne le fera pas. Cron ne le fera pas. Windows Event Log ne le fera pas.
Les applications
1. Healthchecks.io — meilleur dead-man switch avec option auto-hébergée
Healthchecks.io est l’implémentation de référence du modèle dead-man-switch. Chaque tâche planifiée reçoit une URL unique, la tâche fait curl vers cette URL à la fin de son exécution réussie, et Healthchecks alerte si le ping n’arrive pas dans la fenêtre attendue. Périodes de grâce par vérification, ping-with-exit-code (donc curl $URL/fail marque explicitement la vérification comme échouée), et horaires par vérification exprimés sous forme d’intervalle simple ou d’expression cron complète. Slack, Discord, PagerDuty, Gotify, ntfy, courrier électronique, SMS, webhook, et environ vingt autres canaux d’alerte.
Où il y a un problème : Le niveau gratuit hébergé est limité à 20 vérifications ; les ménages avec de grandes surfaces d’automatisation le dépasseront. L’auto-hébergement résout ce problème mais ajoute un service à maintenir.
Plateformes : N’importe quel hôte Linux/Docker pour l’auto-hébergement. Le niveau hébergé fonctionne à partir de n’importe quoi capable de faire une requête HTTP.
Télécharger : Healthchecks.io install
Conclusion : Le défaut correct pour les pulsations de tâches planifiées sur un serveur domestique.
2. Cronitor — meilleure télémétrie cron complète avec statistiques par travail
Cronitor va au-delà de la pulsation et capture la vue d’ensemble complète du temps d’exécution — combien de temps le travail a pris, code de sortie, stdout et stderr, graphiques comparatifs entre les exécutions, et alertes sur tout changement. Enveloppez le travail dans la CLI Cronitor ou pinguez l’URL directement au démarrage, à la fin et en cas d’échec. Le tableau de bord est destiné aux équipes ; un ménage utilisant la moitié des fonctionnalités obtiendra toujours de la valeur des graphiques de temps d’exécution seuls.
Où il y a un problème : Hébergé uniquement — pas de chemin d’auto-hébergement. Le niveau gratuit est de 5 moniteurs, qui se remplissent rapidement sur un serveur occupé.
Plateformes : N’importe quel hôte capable d’effectuer une HTTPS sortante. Wrapper CLI pour Linux, macOS, Windows.
Télécharger : Cronitor download
Conclusion : Le bon choix quand vous voulez des graphiques de temps d’exécution par travail et que vous êtes à l’aise avec un service hébergé.
3. Dead Man’s Snitch — meilleur le service de pulsation original
Dead Man’s Snitch a popularisé le modèle et reste l’un des moyens les plus simples de détecter une défaillance silencieuse. Créez un snitch, obtenez une URL, faites en sorte que le travail atteigne cette URL, obtenez un courrier électronique si l’URL n’est pas pingée dans l’intervalle. C’est tout le produit. Quand « y a-t-il quelque chose qui doit être plus compliqué que cela ? » est la bonne question, Dead Man’s Snitch est la réponse honnête.
Où il y a un problème : Le niveau gratuit est un snitch — c’est suffisant pour protéger un travail critique et rien de plus. La profondeur des fonctionnalités est à la traîne par rapport à Healthchecks et Cronitor.
Plateformes : N’importe quel hôte capable d’effectuer une HTTPS sortante.
Télécharger : Dead Man’s Snitch signup
Conclusion : Le bon choix quand l’alerte « la sauvegarde ne s’est pas exécutée » est le seul résultat que vous devez protéger.
4. Uptime Kuma — meilleur moniteur de disponibilité auto-hébergé avec mode push
Uptime Kuma est le moniteur de disponibilité auto-hébergé qui a développé un mode push approprié aux côtés de ses sondes HTTP et TCP. Interface point-and-click, la plupart des canaux d’alerte qui comptent pour les gens, pages de statut par vérification, et le même modèle « vérification envoyée dans X secondes » qu’Healthchecks. Si le serveur domestique exécute déjà Uptime Kuma pour la pile média, ajouter les pulsations des travaux cron au même tableau de bord ne coûte que quelques clics.
Où il y a un problème : Le support du mode push est plus récent que les sondes du mode pull et c’est là que les bords les plus rugueux sont. Moins spécialisé au cas d’usage de pulsation cron qu’Healthchecks.
Plateformes : Linux (Docker), Windows, macOS.
Télécharger : Uptime Kuma install
Conclusion : Le bon choix quand le ménage exécute déjà Uptime Kuma et ne veut pas d’autre tableau de bord.
5. Prometheus Node Exporter — meilleures métriques pour l’état du timer systemd
Prometheus Node Exporter expédie un collecteur pour l’état de l’unité et du timer systemd. Combiné avec Prometheus et Alertmanager, vous pouvez créer un graphique « quand ce timer s’est-il exécuté avec succès pour la dernière fois », alerter sur « pas d’exécution réussie au cours des N dernières minutes » et corréler avec les métriques système larges (CPU, disque, réseau). C’est l’approche de la robustesse industrielle ; excessif pour un ménage, exactement la bonne forme pour quiconque exécute déjà Prometheus.
Où il y a un problème : Nécessite que l’ensemble de la pile Prometheus soit utile — c’est une véritable infrastructure, pas une installation de cinq minutes. Spécifique à systemd pour le collecteur de timer ; les travaux cron nécessitent une approche différente.
Plateformes : Linux, Windows, macOS, FreeBSD.
Télécharger : Prometheus Node Exporter releases
Conclusion : Le bon choix quand Prometheus est déjà le magasin de métriques sur le labo domestique.
6. systemd — meilleure détection native des défaillances sur Linux
systemd sur Linux moderne a plus de gestion des défaillances intégrée que la plupart des migrants de cron ne le réalisent. Une unité avec OnFailure= déclenche une autre unité en cas d’échec, qui peut être un script mail, un webhook ou un script qui ping Healthchecks. systemctl list-timers affiche l’horaire et la dernière exécution, et systemctl status <unit> affiche le code de sortie et la queue de journal. Pour quiconque utilise déjà les timers systemd, la moitié de la surveillance est déjà dans la boîte.
Où il y a un problème : Vous indique seulement quand le processus a échoué, pas quand le résultat a échoué. Un script de sauvegarde qui s’est terminé mais n’a rien fait d’utile semble vert pour systemd.
Plateformes : Linux (distributions basées sur systemd).
Télécharger : systemd resources
Conclusion : Le minimum correct sur n’importe quel serveur Linux exécutant les timers systemd.
7. Gotify — meilleur serveur de notifications push auto-hébergé
Gotify est le petit serveur Go qui transforme toute requête HTTP en notification push Android. Par lui-même, il ne détecte pas les défaillances ; combiné avec n’importe quel outil ci-dessus, il devient la façon dont les alertes atteignent réellement un téléphone sans dépendre de Firebase Cloud Messaging ou d’un service de notification tiers. Idéal pour les ménages où le canal d’alerte doit être aussi privé que les serveurs surveillés.
Où il y a un problème : Pas un moniteur par lui-même. Nécessite l’installation de l’application Android sur les téléphones récepteurs ; le support iOS dépend de ntfy ou similaire plutôt que de l’application Gotify elle-même.
Plateformes : Linux (Docker), Windows, macOS, FreeBSD.
Télécharger : Gotify install
Conclusion : Le serveur de notifications push derniers kilomètres correct pour une pile d’alertes auto-hébergée.
Comment choisir le bon
- Si vous voulez un dead-man switch qui fonctionne aujourd’hui : Healthchecks.io (auto-hébergé une fois qu’il dépasse 20 vérifications).
- Si vous voulez la télémétrie du temps d’exécution par travail et que vous êtes à l’aise avec un service hébergé : Cronitor.
- Si vous n’avez besoin de protéger qu’un travail critique : Dead Man’s Snitch.
- Si le serveur domestique exécute déjà Uptime Kuma : Uptime Kuma.
- Si Prometheus est déjà le magasin de métriques : Prometheus Node Exporter.
- Si le serveur Linux exécute les timers systemd et que vous voulez la surveillance intégrée : systemd.
- Si vous voulez que les alertes atteignent les téléphones du ménage sans passer par un service push tiers : Gotify.
Pour la plupart des labos domestiques, la combinaison qui fonctionne est Healthchecks (auto-hébergée) comme dead-man switch, câblée à Gotify pour push téléphonique et courrier électronique comme repli. Tout ce qui s’exécute en tant que timer systemd reçoit une unité OnFailure= qui ping le même point de terminaison Healthchecks en cas d’échec pour que les deux signaux se corrèlent.
FAQ
Quelle est la différence entre une pulsation et un health check ?
Une pulsation est le travail qui dit « je me suis exécuté et j’ai réussi ». Un health check est un moniteur qui teste le service pour voir s’il répond. Les pulsations détectent les défaillances silencieuses des tâches planifiées ; les health checks détectent les défaillances du service d’exécution. Vous en voulez les deux.
Où devrais-je envoyer les alertes ?
Quelque part en dehors de la machine surveillée. Le courrier électronique est bien comme repli mais ne devrait pas être le seul canal — si la machine qui exécute le courrier est la machine qui a échoué, l’alerte ne part jamais. Superposez courrier électronique plus push téléphonique (ntfy, Gotify, Pushover) plus canal de chat (webhook Discord, Slack) pour les travaux de haute priorité.
Comment ajouter une pulsation à un travail Windows Task Scheduler ?
Enveloppez l’action dans un petit script PowerShell qui exécute la tâche réelle, vérifie le code de sortie et appelle Invoke-WebRequest à l’URL Healthchecks ou Cronitor uniquement quand tout a réussi. Le crochet « exécuter ceci à la fin » de Task Scheduler ne distingue pas proprement entre succès et échec, alors faites-le dans le script.
systemd est-il vraiment suffisant pour la surveillance Linux ?
Pour « le processus a-t-il échoué ? » — oui. Pour « le résultat a-t-il eu lieu ? » — non. Combinez OnFailure= de systemd avec une pulsation que le travail envoie seulement après la fin de son travail réel pour la vue d’ensemble complète.
Dois-je toujours surveiller cron lui-même ?
Oui. Cron peut s’exécuter et être sain alors que les travaux individuels cessent silencieusement de tirer (mauvaise syntaxe crontab, changement de permission, utilisateur manquant). Uptime Kuma ou Healthchecks peuvent également surveiller l’heure de dernière exécution de cron sur un serveur domestique ; si cela devient ancien, cron c’est ce qui a besoin d’attention.
