Canceled and skipped Sume agent runs send no webhook: what to poll
A Sume run webhook fires only when a run completes or fails. Canceled and skipped runs send nothing, so your scheduler must read status_url for them.
Waiting for a webhook on a run that was canceled or skipped will wait forever. Sume's run webhook sends one signed POST when a run completes or fails, and nothing for canceled or skipped. After you call cancel, accept the response and poll status_url until the status is canceled. For a skipped run, the create response already told you.
This applies to all three run families (Action, Format and Agent Completion), each with one terminal event: action.run.terminal, format.run.terminal and agent.run.terminal.
Which outcomes notify you
From the Run webhooks and Runs and results pages, read 2026-10-09.
| Terminal status | Webhook? | What your code should do |
|---|---|---|
completed | Yes, status: OK | Branch on outcome: ok, or degraded when output is null but artifacts exist |
failed | Yes, status: ERROR | Read payload and error; the receipt still has artifacts |
canceled | No | Poll status_url after POST ...cancel |
skipped | No | Read status and skip_reason (previous_run_active) on the create response; next_action is retry_later |
Why skipped runs surprise agent schedulers
A schedule's on_active_run defaults to skip. If a nightly run is still going when the next trigger fires, the new run is recorded as skipped immediately, with no work started, so no completion exists to announce. A job runner that only listens for webhooks will see nothing and may assume the trigger never fired.
Choose reject instead if you want the conflict to be an error at the API, or keep skip and have your runner treat a skipped receipt as a normal event. Format runs differ: their default is allow, which runs concurrently.
A small reconciliation rule
Do not make the webhook your only source of truth.
- Store every run id you create along with its create-time status.
- On a timer, list runs still not terminal and read their
status_url. - Mark
canceledandskippedas done when you see them; do not retry on a missing webhook. - Dedupe webhook deliveries on
request_id, which equals the run id and is stable across retries.
Example: a cancel that never reports
A scheduler decides a run is too slow and posts to cancel_url. The response is accepted, but a webhook handler waiting for agent.run.terminal never fires. The correct flow is to poll status_url with a short backoff until payload.status reads canceled, then mark the run closed in your own database. If you also set a deadline, treat a run that is still processing after the cancel as a case for an alert, not for another cancel loop.
The same thinking covers the receipt for an oversized run: the webhook then carries payload: null and an error pointing at result_url, so even completed runs sometimes need a fetch. Design the handler so that fetching the receipt by run id is its normal fallback.
Sources
Related posts
More in Agents
- A 20,000-character narration fits a $1.00 scheduled cap at $0.95
Sume TTS at $0.0475 per 1,000 characters prices 20,000 characters at $0.95, 5 cents under the $1.00 default cap of a schedule. What 21,000 does.
- Unattended agent: stop or retry on Sume 402, 409, 429, 503?
An unattended Sume agent should stop on 402, fix on 400, retry 429 and 503 with the same idempotency key, and never reuse a key after a 409.
- Wan 3.0 clip lengths that fit a $1.00 scheduled run cap
A schedule without its own cap gets $1.00 per run. At Wan 3.0 rates that buys 16 s at 480p, 8 s at 720p or 4 s at 1080p; here is the table.
- Your agent calls generate_video, or Sume's agent does: two meters
With hosted MCP your model client runs the loop and you pay its provider; with an Agent Completion Sume's agent runs it and you set generation_spend_cap_usd.
Written by Sume