Debugging a Failed Run with an AI Assistant

A schedule you built — or inherited from a colleague — just failed, and you don't want to dig through the log yourself. With an assistant connected over MCP, you can hand it the whole diagnose-and-repair loop: reading the log, finding the cause, and updating the script.

Point it at the failure

My nightly-backup schedule in the Ops project failed last night. What happened?

The assistant lists recent runs for that schedule, finds the failed one, and pulls its log via get-run and get-run-log. It replies with what actually went wrong — for example, a missing environment variable, an unreachable host, or a dependency that failed to install — rather than just pasting the raw log back at you.

Ask for a fix

If the cause is something the script itself can handle:

Fix the script so it retries the S3 upload up to three times before failing.

The assistant rewrites the schedule's Command field directly and the fix is live immediately. If the cause is external to the script instead — for example, a secret that expired — it tells you what to change, since it can't act on things outside Runner's reach:

The database password in that script's environment variable looks wrong — you'll need to update it, then I can re-run the job to confirm.

Confirm the fix

Run it now and show me whether it passes this time.

The assistant triggers the schedule with run-schedule and reports back once the new run finishes. If it still fails, it can pull the new log and continue iterating without you switching back to the Runner UI at all.

When to step in yourself

Treat this as a fast first pass, not a substitute for review — especially for schedules that touch production data or credentials. Read what changed in the script before trusting it with real infrastructure, the same way you would review a colleague's fix. See Building a Schedule From a Prompt for how these scripts get created in the first place, and Runs for what each run status means.