Check that your scheduled jobs actually ran, with AI
An agent reads a list of cron jobs with their last run times and flags the overdue and failing ones in plain English.
- Read-only connection
- Scheduled
- Callback
- Budget cap
Watch a real run
A real run on Oct 7, 2026, replayed. Model: openai/gpt-6-luna.
- Queuedbudget $0.025 reserved
- MicroVMmicroVM ready
- MicroVMworker started · shell off · web off
- Connectionops GET /jobs
- Result
ops GET → 200 - MicroVMmicroVM destroyed
- Succeeded2 model calls, 3,246 tokensRecorded output (English)
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 destroyed$0.002811 charged, $0.022189 released
Run it yourself
Open the sample in the playground with the whole request filled in. It runs on your own account, within the budget shown, against the same read-only sample systems.
Budget for this sample: $0.025
How it works
Silent cron failures are the expensive kind. The agent compares each job's last run to its expected interval and reports jobs that are overdue or failing, with the evidence. The jobs API is read-only and reports its own clock, so the answer does not depend on the agent's calendar.
What the agent can and cannot do
The permissions are part of the request. Anything not listed here is not available to the run.
| Setting | Allowed |
|---|---|
| Connections | ops: GET only, at ephemer.al/api/samples/ops-api |
| Web | Off |
| Shell | Off |
| Files | None |
| Zero data retention | Off: the record is kept for 30 days |
| Budget | $0.025, a hard cap |
| Timeout | 60 seconds |
Credentials never enter the machine: a broker adds them to each call and enforces the methods above.
The code
This is the exact request the sample sends. Set EPHEMERAL_API_KEY to a member key of your organization.
curl -X POST $EPHEMERAL_URL/v1/runs \
-H "Authorization: Bearer $EPHEMERAL_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
-d @request.jsonFull request body workflow.json
The same body, with the files inline.
{
"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
}This sample runs on a timetable: 0 * * * * in UTC. A schedule starts a saved workflow, so save the request as a workflow first, then create the schedule.