Why a Scheduled Action run says skipped: previous_run_active

A Sume Scheduled Action recorded status skipped with skip_reason previous_run_active. It means the last run was still going. Here is how to react.

4 min readSume
All posts

When a Scheduled Action run shows skipped with skip_reason: previous_run_active, the previous run of that action had not finished when the new trigger fired, so Sume recorded the new one instead of starting a second. The receipt also carries next_action: retry_later. Nothing failed; the earlier run is the one doing the work.

What the receipt tells you

Skipping is the default for Scheduled Actions. It is the same idea as on_active_run: skip on a Format run, but for actions it is already set, so a cron that fires every five minutes does not stack up copies of a 20-minute job.

Fields from docs.sume.com/agents/actions/runs, checked 2026-10-01
FieldValue on a skipped run
statusskipped
skip_reasonprevious_run_active
next_actionretry_later
trigger.sourcecron, manual or api

What to do about it

First decide whether skipping is correct. If every run covers a different input, such as a new episode each week, a skip means a window was lost and you should either lengthen the gap between triggers or shorten the work. If the runs are idempotent (check a feed, do nothing if empty), a skip is harmless.

For API-triggered runs, treat retry_later as an instruction: wait, then call POST /v1/actions/{action_id}/runs again, rather than looping at once. Read the earlier run with GET /v1/action-runs/{run_id}/status to see whether it is stuck or just slow, and cancel it only if it is stuck.

  • Shorten the work: split a big task into two actions on different schedules.
  • Lengthen the cron interval beyond the usual run time.
  • Count skips in your own monitoring; a streak means the interval is too short.

Monitoring skips

Treat the skip rate as a health metric. A single skip after a slow week is normal; a skip on every trigger means the interval is shorter than the work. Record trigger.source too: a manual or API trigger that lands during a cron run will itself be skipped, which can look like a failed deploy of your own automation when it is simply a collision.

Limits

A skipped run has no output to read. If you need every trigger to produce a result, use Agent Completions or Format runs with on_active_run: allow instead; both can run at the same time, subject to the workspace's generation concurrency. See Prevent overlapping AI agent runs for the options side by side.

Related posts

More in Agents

All Agents posts

Written by Sume