Scheduled Sume run missing from /v1/jobs: it is not a job

A scheduled run does not appear in /v1/jobs because it is not a generation job. Sume's docs say it does not use the job lifecycle at all. You read it from /v1/action-runs/{run_id}, and jobs_wait and jobs_list are the wrong tools for it. The run may start generation jobs while it works, but the run itself is an Agent doing saved instructions in a fresh thread.

Run versus job

This table is condensed from the Scheduled page. The statuses list is the one point that matters in code: a run can end as skipped, which a job never does.

What to build

Poll the run's receipt, not the job list. Do not look for the run in a jobs dashboard, and do not try to attach a jobs_wait to a run id. If you want to see what the run generated, read its output and artifacts once it completes.

The docs also say the receipt's events_url is always null today. Use status_url and result_url instead, and do not build a progress bar on events.

• Check for skipped as a normal outcome when the overlap policy is skip.
• Treat failed and canceled as separate from skipped in alerts.
• Reading generation jobs started by a run is a separate step, with the job ids the run produced.

The tradeoff

Separating runs from jobs keeps a schedule's own life cycle, with overlap rules and a spend cap, apart from single model calls. The cost is that you now have two places to look when a scheduled output seems wrong. Start with the run's status and output, and only then look at generation jobs.

A practical alert rule follows from this. Page someone on failed runs, log skipped runs at a lower level, and keep a count of how many generation jobs each run started. If the counts drift from what you expect, open the run's output first, because the run's instructions, not the job queue, decide what gets generated.