Workflow run issues

Use this page when a workflow run doesn't start, starts in the wrong place, fails at a step, or you can't find what it produced. "Automations" was the old name for this feature — it's all workflows now. Workflows are scoped to the person who created them; there's no Team ownership or shared org surface in this form yet.

Read the run's status first

A run's page shows a live status pill that usually tells you what happened before you go digging:

• Queued / Starting / Running / Waiting for approval are in-flight. The page polls while a run is active and stops once it's terminal.
• Completed / Failed / Cancelled are terminal. Cancelled means someone stopped it (or took back a bound session); a cancelled run can't be resumed, only re-launched.
• Over budget is a Cloud run that never started because the owner's usage budget was exhausted at delivery time. This applies to manual, scheduled, and poll-triggered Cloud runs in enforcement-mode billing. Nothing was provisioned. Bring usage back under budget, then launch again or wait for the next trigger occurrence; the blocked run doesn't retry itself. Local runs do not pass through this Cloud delivery gate.
• Missed is a scheduled occurrence the scheduler recorded but didn't fire, per the trigger's missed-run policy. It's honest history, not a failure, and it's terminal by design.

A step that needs an integration failed

Integrations (Issues, Slack today) are granted at the workflow level and are all-or-nothing per namespace. Two common causes when a step that uses one fails:

• The run wasn't in Cloud. A workflow that grants an integration needs a Cloud run — a local run fails explicitly at the step that needs it. Re-launch with Run location set to Cloud.
• The connected account isn't ready. If a provider the workflow needs isn't connected, the launch modal shows the error in place and, when it can, links straight to Settings → Integrations. Connect the account and re-launch.

The run started in the wrong repo or workspace

Where a run executes comes from the launch modal, not a saved owner setting:

• A manual run uses the Run location and Workspace you picked in the modal, pre-filled with wherever the workflow last ran. Check those before you launch.
• A scheduled run uses the repository pinned on the schedule trigger, and the workspace is derived and warmed for you. Fix the pin in the trigger editor if it's aimed at the wrong repo.

You can't find what a run produced

A cloud run doesn't work in your workspace's main checkout. It mints a fresh git worktree scoped to that run, branched off the workspace's checkout at launch. Branches, commits, and pull requests come from that worktree, and it sticks around after the run finishes:

• Use Open session on any step tied to an agent session — it opens the real checkout that run worked in, branch and all, even long after the run is done.
• Two runs against the same workspace get two separate worktrees and two separate branches; they don't see each other's uncommitted changes.

For a local run there's no sandbox to isolate: it works directly in the local workspace you picked, the same as a session you started by hand.

A schedule didn't fire when you expected

• A schedule targeting a cloud workspace starts without an open device. An On this Mac occurrence still comes due while the app is closed, but it waits in a claimable state until one of your signed-in Desktop apps is open. The schedule stores a repository identity, not a device ID: another Mac signed in as you can claim it, and a claimant without that repository fails the run. Keep other signed-in Macs closed for device-specific jobs.
• If the scheduler was down, or Skip this run held the cursor while a prior run was active, the trigger's missed-run policy decides the overdue window: run only the latest occurrence (default), skip them all, or replay every one. Every occurrence gets a row either way — a Missed row is not a silent drop. In this beta, Skip every missed occurrence also suppresses a window containing only the normally due occurrence; use the default policy unless that is what you want.
• Queue after serializes Cloud delivery, but the current local claim path can deliver a later occurrence before the previous local run finishes. Use Skip this run for an On this Mac schedule that must not overlap. See scheduling a workflow.

A poll trigger stopped producing runs, or rejects items

• A poll item's data is checked against the workflow's declared inputs before it reaches an agent. A missing required field, wrong type, or run-start failure records that item as consumed and advances the page cursor; it does not retry under the same item ID. Fix the source and publish a new item ID, or adjust the workflow's inputs. Valid siblings on the same page still run.
• has_more: true does not drain another page immediately. The saved cursor is used on the trigger's next polling interval.
• If nothing is polling at all, re-check the endpoint URL and auth header; a broken endpoint usually fails setup validation before the trigger can save. See polling triggers.

A session is locked and you can't type in it

If you bound a live session to a run, that session is locked until the run ends. To get it back, or to stop the run outright, use Cancel run in the run's header — cancelling releases the bound session immediately. There's no resume afterward.

For the full model behind triggers, run locations, and isolation, see Workflows, running a workflow, and execution and isolation.