La surveillance des tâches planifiées & du signal de présence qui détecte les échecs silencieux.
Une tâche planifiée morte ne génère aucune erreur et n'écrit aucun journal — vous le découvrez le jour où vous avez besoin de la sauvegarde. Donnez une URL de ping à chaque tâche et Uptimia ouvre un incident dans la minute suivant l'échéance manquée.
Pulse — last 2 hours
one blip per ping received · 24 expectedHow this check works
hb_9f2c41d8a03b57e6The ping — one line of cron
crontab · queue-workerPing log
every signal we received, newest firstLa sauvegarde qui n'a pas tourné
Une sauvegarde de base de données nocturne, programmée à 03:30. Le script est mort avant de pouvoir envoyer son ping — rien n'a signalé d'erreur, rien n'a été journalisé, et le seul signal était le ping qui n'est jamais arrivé.
Surveillez les tâches planifiées où qu'elles s'exécutent
Si elle peut envoyer une requête HTTP, Uptimia peut la surveiller — les pings sont uniquement sortants, donc les tâches derrière un pare-feu ou un NAT signalent leur passage sans problème.
Horaires, signaux et journal de pings
Alerté en moins d'une minute
Chaque sonde est vérifiée toutes les 60 secondes. Une échéance manquée au-delà de votre délai de grâce ouvre un seul incident et déclenche les alertes — pas de rafales répétées, et la clôture n'intervient que sur un ping réel.
- Échelles d'escalade et liens d'acquittement en un clic — aucune connexion nécessaire
- Avis de rétablissement quand la tâche revient
- Fenêtres de maintenance et pause — pas de fausses alertes pendant les déploiements
Votre expression cron, votre fuseau horaire
Collez la ligne déjà présente dans votre crontab, ou fixez un simple intervalle de 30 secondes à 90 jours. Les échéances suivent l'heure d'été, donc une tâche de 03:30 reste une tâche de 03:30 même en octobre.
- Toute expression cron à cinq champs — plages, pas, noms, macros de type @daily
- Un délai de grâce que vous fixez par tâche — une tâche qui déborde parfois n'alerte personne
- Les horaires invalides ou impossibles sont rejetés à l'enregistrement
votre fuseau horaire
Chaque exécution dans le journal de pings
Ouvrez une sonde et voyez quand la tâche a tourné pour la dernière fois, si elle dérive semaine après semaine, et la durée de chaque exécution — sans avoir à vous connecter à la machine.
- Bande de pulsation sur 12 heures et un graphique des pings par heure comparé au taux attendu
- Durée d'exécution à chaque ping quand la tâche envoie un signal de démarrage
- Pings tardifs signalés dans le journal — jamais alertés
attendu 4 / heure — 09:00 en a reçu 3
start 09:45:01 · success 09:45:03 → run 2.1 s
Détecte les blocages et les plantages, pas seulement le silence
Trois signaux couvrent chaque façon dont une tâche peut échouer. Le succès remet le compte à rebours à zéro ; le démarrage active un plafond de durée d'exécution, si bien qu'une tâche bloquée alerte même si elle ne se termine jamais ; l'échec alerte immédiatement.
- /start — durée d'exécution dans le journal, plus détection de durée maximale
- /fail — incident immédiat, délai de grâce ignoré
- Fonctionne depuis n'importe quel client HTTP — curl, wget, PowerShell ou votre propre code
d'échec
Comment fonctionne la surveillance par signal de présence
Une URL par tâche — aucun agent, aucune bibliothèque.
Créez une sonde
Nommez la tâche et fixez son horaire — intervalle ou cron. L'enregistrement génère une URL de ping privée.
Ajoutez une ligne à la tâche
Ajoutez un curl, ou copiez un extrait prêt à l'emploi — Crontab, Bash, PowerShell, GitHub Actions ou PHP. La sonde s'arme d'elle-même au premier ping.
30 3 * * * /usr/local/bin/db-backup.sh \
&& curl -fsS -m 10 --retry 3 \
https://uptimia.com/p/hb_9f2…c41 >/dev/null
# le premier ping réel arme la sonde :
✓ ping reçu — db-backup · nightly est armée
Soyez alerté dès qu'elle se tait
Échéance manquée plus délai de grâce = un incident. Votre équipe est alertée en moins d'une minute, sur les canaux qu'elle utilise déjà.
Ajoutez une ligne à la tâche.Sachez-le la nuit où elle s'arrête.
Chaque tâche, chaque ping, chaque canal d'alerte — gratuit pendant 30 jours, et rien de tout cela n'est un module payant.
Également inclus
API REST complète
Créez, modifiez, mettez en pause et supprimez des signaux de présence depuis votre pipeline — plus un point de terminaison de prévisualisation cron qui valide les expressions avant leur mise en production.
Extraits avec votre jeton déjà renseigné
Crontab, Bash, PowerShell, GitHub Actions et PHP.
Réinitialisation du jeton en un clic
L'ancienne URL meurt dès que vous régénérez le jeton.
Limites de débit adaptées au NAT
Comptées par sonde, pas par IP — les flottes de workers sont les bienvenues.
Pings de test
Envoyez-en un depuis le panneau pour le voir dans le journal.
Tous les types de sondes dans un seul compte
Les mêmes groupes, la même liste de contacts et les mêmes rôles que tout autre type de sonde.
Où vos alertes arrivent
Une sauvegarde manquée atteint les mêmes personnes, sur les mêmes canaux, qu'un site tombé en panne.
12 canaux, une seule liste de contacts — configurez-la une fois, chaque type de sonde l'utilise.
Parcourir l’annuaire complet des intégrations →Qu'est-ce que la surveillance des tâches planifiées & du signal de présence ?
La surveillance des tâches planifiées — aussi appelée surveillance par signal de présence — vérifie que les tâches planifiées s'exécutent réellement. Plutôt qu'Uptimia interroge votre serveur, chaque tâche envoie une courte requête HTTP (« ping ») vers sa propre URL unique lors de son exécution. Si le ping n'arrive pas à l'heure prévue plus le délai de grâce, Uptimia ouvre un incident et vous alerte.
Surveillance de la disponibilité
Fonctionne quand il y a quelque chose à interroger. Sites web et API répondent ; une tâche planifiée, non.
Surveillance par signal de présence
pas de ping avant 03:32 → l'incident s'ouvre · un ping /fail alerte instantanément
Un dispositif homme mort pour cron
Chaque sonde de signal de présence Uptimia en est un — horaires adaptés au cron, délai de grâce, et alertes partout où votre équipe travaille.
FAQ sur la surveillance par signal de présence
01Que doit réellement faire ma tâche ?+
curl -fsS -m 10 --retry 3 https://uptimia.com/p/hb_… à la fin de la ligne crontab suffit. GET, POST et HEAD fonctionnent tous. La sonde reste en dormance jusqu'à son premier vrai ping, elle ne peut donc pas alerter pendant que vous la configurez.02Quand exactement une alerte se déclenche-t-elle ?+
/fail alerte immédiatement, et rien ne réalerte tant qu'un incident est ouvert.03Ma tâche se bloque au lieu de planter — le détectez-vous ?+
/start au début de l'exécution et fixez une durée maximale. Si aucun succès ne suit dans ce plafond, un incident s'ouvre. Vous obtenez aussi la durée de chaque exécution dans le journal.04Pourquoi ma tâche cron n'a-t-elle pas tourné ?+
05Puis-je surveiller des CronJobs Kubernetes, GitHub Actions ou des tâches Windows ?+
06Quelles données conservez-vous par ping ?+
07Nous envoyons des pings depuis des centaines de workers derrière un seul NAT — est-ce un problème ?+
08Dans quel fuseau horaire s'exécutent les horaires cron ?+
09Puis-je gérer les signaux de présence sans l'interface ?+
10Un aperçu de lien peut-il faire passer accidentellement une tâche morte pour vivante ?+
11La surveillance par signal de présence est-elle un module payant ?+
Votre prochaine tâche manquée devrait vous alerter.
Une ligne à la fin d'une tâche la place sous surveillance — aux côtés de vos sondes de disponibilité, SSL et serveur.