Vérifier avec l'IA que vos tâches planifiées se sont vraiment exécutées
Un agent lit une liste de tâches cron avec leur dernière exécution et signale en langage clair celles qui sont en retard ou en échec.
- Connexion en lecture seule
- Planifié
- Callback
- Plafond de budget
Regardez une vraie exécution
Une vraie exécution du 7 oct. 2026, rejouée. Modèle : openai/gpt-6-luna.
- En file d'attentebudget de $0.025 réservé
- MicroVMmicroVM ready
- MicroVMworker started · shell off · web off
- Connexionops GET /jobs
- Résultat
ops GET → 200 - MicroVMmicroVM destroyed
- Réussie2 appels au modèle, 3,246 jetonsSortie enregistrée (en anglais)
Ops check at 2026-10-07 09:00 UTC: 2 jobs need attention; 6 are healthy.
- invoice-export — Overdue: last ran 2026-10-05 03:00 UTC, 54 hours ago; expected every 24 hours (overdue threshold: more than 36 hours). No run is recorded on Oct 6 or 7. Next step: investigate the missed runs and trigger an export if needed.
- sync-inventory — Failing: last ran 2026-10-07 08:30 UTC and status is
failed; error:401 Unauthorized from supplier API: token expired. Next step: renew the supplier API token and retry.
- Worker détruit$0.002811 facturé, $0.022189 libéré
Lancez-le vous-même
Ouvrez l'exemple dans le playground avec toute la requête déjà remplie. Il s'exécute sur votre propre compte, dans le budget indiqué, sur les mêmes systèmes d'exemple en lecture seule.
Budget pour cet exemple : $0.025
Fonctionnement
Les échecs silencieux de cron sont les plus coûteux. L'agent compare la dernière exécution de chaque tâche à son intervalle attendu et signale les tâches en retard ou en échec, preuves à l'appui. L'API des tâches est en lecture seule et indique sa propre horloge : la réponse ne dépend donc pas du calendrier de l'agent.
Ce que l'agent peut et ne peut pas faire
Les permissions font partie de la requête. Tout ce qui n'est pas listé ici n'est pas disponible pour l'exécution.
| Paramètre | Autorisé |
|---|---|
| Connexions | ops : GET uniquement, sur ephemer.al/api/samples/ops-api |
| Web | Désactivé |
| Shell | Désactivé |
| Fichiers | Aucune |
| Rétention zéro des données | Désactivée : l'historique est conservé 30 jours |
| Budget | $0.025, un plafond strict |
| Délai | 60 secondes |
Les identifiants n'entrent jamais dans la machine : un broker les ajoute à chaque appel et impose les méthodes ci-dessus.
Le code
Voici la requête exacte envoyée par l'exemple. Définissez EPHEMERAL_API_KEY avec une clé de membre de votre organisation.
curl -X POST $EPHEMERAL_URL/v1/runs \
-H "Authorization: Bearer $EPHEMERAL_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
-d @request.jsonCorps complet de la requête workflow.json
Le même corps, avec les fichiers en ligne.
{
"prompt": "Read GET /jobs on the ops connection. Use the 'now' value in the response as the current time. A job is overdue when more than 1.5 times expected_every_hours have passed since last_run_at. A job is failing when last_status is failed. Reply in Markdown, at most 150 words: one headline sentence, then a bullet for each overdue or failing job with its name, the evidence (times and error) and a likely next step. Do not list healthy jobs, just say how many there are. Use only what the data returns and never guess; if a call fails or a field is missing, say so.",
"connections": {
"ops": {
"type": "http",
"url": "https://ephemer.al/api/samples/ops-api",
"auth": {
"type": "bearer",
"token": "sample_read_key"
},
"allowed_methods": [
"GET"
],
"instructions": "GET /jobs returns now (the current time) and items with name, schedule, expected_every_hours, last_run_at, last_status, last_error, recent_statuses (newest first) and sometimes a note."
}
},
"shell": false,
"timeout_seconds": 60
}Cet exemple s'exécute selon un calendrier : 0 * * * * dans le fuseau UTC. Une planification lance un workflow enregistré : enregistrez d'abord la requête comme workflow, puis créez la planification.