Surveillance d’agents IA
Votre agent a signalé un succès.
Il n’a rien produit.
Les agents planifiés échouent en silence. Une exécution qui n’a jamais démarré, une boucle qui avale une erreur d’outil et sort en 0, un appel de modèle qui ne revient jamais. SteadyCron surveille le résultat plutôt que le code de sortie, et vous prévient quand un vrai résultat cesse d’arriver.
Sans carte. Un moniteur d’agent gratuit, toutes les règles incluses.
Ce à quoi l’exécution a ressemblé
02:00 exécution planifiée démarrée
02:04 processus terminé en 0
02:04 ✓ marquée réussie
# out/digest.md → 0 octet
# tokens consommés : 84 300
# quelqu’un alerté ? non Ce qu’il fallait vraiment savoir
02:00 /start exécution démarrée
02:04 rapport : items=0
02:04 règle : empty_result → échec
→ #ops-slack nightly-digest en échec
dernière bonne exécution : hier 02:03 Le problème
Pour un agent sans surveillance, le silence ressemble au succès
Les frameworks d’agents sont conçus pour continuer. Un appel d’outil échoue, le modèle s’excuse et poursuit, la boucle se termine proprement sans rien avoir écrit. Le processus sort en 0 parce qu’il s’est terminé, pas parce que du travail a eu lieu.
Tourner sans surveillance était tout l’intérêt, donc personne ne lit la sortie. Le planificateur ne signalera pas un calendrier mort, le fournisseur ne signalera pas un budget épuisé, et l’agent ne signalera pas sa propre exécution vide.
La distinction qui compte
Un agent qui signale que tout va bien avec un débit nul n’est pas en bonne santé — il est asymptomatique.
- Code de sortie 0 sans artefact — l’échec d’agent le plus courant, et celui que tout contrôle de disponibilité valide.
- L’exécution n’a pas démarré du tout : workflow désactivé, machine endormie, événement de planification abandonné.
- Un appel de modèle sans délai d’attente bloque l’exécution des heures, et les suivantes s’empilent derrière.
- Limites de débit, budget épuisé ou clé d’API renouvelée mettent fin à l’exécution de ce soir — et à celle de demain.
- Un identifiant de modèle déprécié ou une réponse remodelée casse votre parsing au calendrier du fournisseur, pas au vôtre.
Trois échecs qui méritent une alerte
Détectés par une attente de calendrier, pas par une trace d’exécution
Les outils de traçage enregistrent ce qu’une exécution a fait. Aucun ne peut enregistrer une exécution qui n’a jamais eu lieu — il n’y a pas de trace à émettre. Cela demande quelque chose qui observe de l’extérieur, à l’heure.
L’exécution n’a jamais eu lieu
GitHub Actions a désactivé le workflow après 60 jours sans activité sur le dépôt. Personne ne l’a remarqué pendant trois jours, car une exécution qui ne démarre pas ne produit ni journal, ni erreur, ni trace.
Seule une attente de calendrier externe détecte une absence. C’est l’échec que votre stack d’observabilité ne peut structurellement pas voir.
Elle a tourné, et n’a rien produit
L’outil de recherche a échoué, le modèle s’est excusé, la boucle s’est terminée. Quatre minutes de tokens dépensés et zéro ligne écrite — signalé comme un succès, car le processus s’est terminé sans lever d’exception.
Votre exécution rapporte le nombre ; la règle « résultat vide » transforme un zéro en échec et en alerte. Rien à implémenter de votre côté.
Elle a bloqué sur un appel de modèle
Beaucoup de SDK sont livrés sans délai d’attente sur les requêtes. Une connexion coincée et l’exécution ne se termine jamais. Le ping /start est arrivé ; /success jamais.
La détection de blocage transforme un appel coincé en alerte à une échéance que vous fixez, au lieu d’une exécution qui ne finit jamais.
Le brancher
Cinq lignes, où que tourne votre agent
Pinguez au démarrage, et ne pinguez le succès qu’après avoir vérifié que la sortie existe. Cette seconde moitié est toute l’astuce — c’est elle qui transforme une exécution vide en alerte.
# Anthropic runs the schedule — but a routine that gets skipped, or
# finishes with nothing, tells nobody. Connect SteadyCron's MCP server
# and the agent reports its own runs with a tool call.
MCP server: https://api.steadycron.com/mcp
Auth: Bearer <your SteadyCron API key>
# Then, in the routine's prompt:
Call report_run_start with jobKey "nightly-digest" before you begin.
This is required — report_run is refused if no run is open.
Do the work. Write the result to out/digest.md.
When you are done, count what you actually produced and call report_run
with that count. If you produced nothing, report 0 — do not omit the
field, and do not round up.
report_run { jobKey: "nightly-digest", itemsProduced: 42,
model: "claude-opus-5", tokensIn: 18400, tokensOut: 2100 }
# SteadyCron turns a 0 into a failed run and an alert. No curl to get
# wrong, and a tool call is far harder for the model to skip than a
# sentence in the prompt. Les bases des pings, de la période de grâce et de la détection de blocage dans Surveillance heartbeat. Le guide détaillé par plateforme n’existe pour l’instant qu’en anglais.
Périmètre
Une question étroite, traitée de façon fiable
SteadyCron n’est pas un outil de traçage LLM et ne prétend pas l’être. Il observe l’exécution, pas le raisonnement.
Ce que ça fait
- Alerte quand une exécution planifiée n’a jamais eu lieu — le seul échec qu’une trace ne peut pas enregistrer.
- Alerte quand une exécution se termine sans rien avoir produit. Nous vérifions le nombre que votre exécution rapporte : rien à implémenter de votre côté.
- Alerte quand une exécution dépasse votre plafond de coût — par exécution ou sur le mois.
- Alerte quand le nombre d’étapes ou d’appels d’outils indique une boucle.
- Alerte quand une exécution démarre et ne finit jamais, face à une durée maximale que vous fixez.
- Suit le coût de chaque agent, avec un total du mois en cours par moniteur.
- Maîtrise le bruit — périodes de grâce, seuils d’échecs consécutifs, heures calmes, résolution automatique.
Ce que ça ne fait pas
- Des traces détaillées de chaque appel de modèle et de chaque outil.
- La gestion des prompts, les jeux de données ou l’évaluation par LLM juge.
- Noter la qualité des réponses, ou détecter les hallucinations.
- Vous dire pourquoi le modèle a pris telle décision.
Pour cela, prenez un outil de traçage — Langfuse, LangSmith et compagnie le font bien. Mettez l’URL de la trace dans la charge utile du ping et votre alerte pointera directement sur l’exécution. SteadyCron répond aux questions qu’ils ne peuvent pas traiter : a-t-elle tourné, a-t-elle fini, a-t-elle produit quelque chose — et combien a-t-elle coûté ?
Où résident les données
Les exécutions d’agents sont les journaux les plus sensibles que vous ayez
Un script de sauvegarde journalise « terminé ». Une exécution d’agent transporte des prompts, des documents récupérés, des arguments d’outils et toutes les données client passées par la fenêtre de contexte — et vous êtes sur le point d’en envoyer un résumé à un prestataire de surveillance.
SteadyCron tourne sur des serveurs Hetzner en Allemagne, exploités par une entité juridique allemande, sous un DPA en libre-service que vous pouvez lire et signer sans appel commercial. Et vous choisissez ce qui part dans le ping : attachez un nombre de lignes, pas les lignes.
- Hetzner, Allemagne
- Entité juridique allemande
- DPA en libre-service
- Liste publique des sous-traitants
Une plateforme pour chaque tâche planifiée
Exécution HTTP
Appelez vos endpoints à l’heure prévue — réessais, délais et journaux complets.
Surveillance heartbeat
Surveillez les tâches que vous exécutez partout ; soyez alerté dès qu’une se tait.
Surveillance d’agents IA
Vous êtes iciSachez quand un agent planifié saute une exécution — ou se termine à vide.
Cron as code
Déclarez chaque tâche, moniteur et alerte en YAML ou Terraform.
Pointez un moniteur sur l’exécution de ce soir
Créez un moniteur heartbeat, indiquez le calendrier que votre agent doit tenir, et ajoutez le ping. Si le résultat de demain n’arrive pas, vous le saurez avant qu’on vous le demande.
- Plan gratuit, sans carte
- 1 moniteur d’agent gratuit
- Hébergé dans l’UE
- Payant à partir de 10 €/mois