Troubleshoot a run
Every failed run tells you why, in two places: the terminal reason on the run’s detail page, and the step-level record in its Execution Log. Start with the reason, confirm in the log, and match what you find against the table below.
Reading a failed run
Open the run from the agent’s Run History. Run Details shows the state, trigger, timing, model, and — for anything that didn’t succeed — the terminal reason. The Execution Log below it replays the run: each step’s input, result, and error, any pauses, and the failure report naming which step broke and after how many attempts.
Terminal reasons
| Reason | What happened | What to do |
|---|---|---|
| Approval expired without resolution | A tool needed approval and nobody answered within an hour. | Approve faster, schedule when the owner is around, or move the tool to Allow if it has earned it. |
| Skipped because another run for this schedule is already active. | The slot fired mid-run. | Usually fine. Chronic skips mean the plan is slower than the schedule — widen the interval or shrink the plan. |
| Run produced no progress for too long; abandoned by the scheduler. | No progress for 6 hours. | Look at the log’s last step; typically a step stalled on an unresponsive service. |
| Approval was never resolved; run abandoned by the scheduler. | Paused on a human for 7 days. | The run is closed; resolve why nobody was watching. |
| Execution idle for … ; run aborted. | The agent went silent for 15 minutes mid-step. | Break long steps up, or check whether the tool call itself hung. |
| One or more internal steps ended in an error state. | The run finished but a step inside it failed. | Open the failure report in the Execution Log for the step and error. |
| Identity assumption failed / Session creation failed | The run could not start. | Usually access changed since save — re-save the agent; if it persists, ask an administrator. |
Common step errors
“Missing … credential. Add the … API key in your organization’s secrets.” — the organization has no key for the model provider this agent uses. An administrator adds one under Settings → Secrets.
“You do not have permission to execute MCP tool …” — policy denied the call. The denial is also an audit event. If the agent genuinely needs the tool, an administrator sets it to Allow or Approve in Settings → Policies.
“Tool … is not available in this session.” — the plan names a tool the run couldn’t reach, most often because its server failed to initialize or was disabled after the plan was saved. Check the server in the MCP Registry, refresh its tool list, and re-save the plan.
“Reconnect … to continue this run.” — a service credential expired mid-run. The run pauses rather than fails: open the session, reconnect the service, and the run resumes where it stopped. See Credentials.
“MCP tool call timed out after 180s.” — the upstream server took longer than three minutes on one call. Retry accounting applies as normal; chronic timeouts are an upstream problem worth raising with whoever runs the server.
“Scheduling blocked by policy” (at save time) — you lack permission for the agent, a provider, or a tool the plan uses. The message names which. An administrator can grant it, or the plan can drop the tool.
Provider errors
Model providers rate-limit and meter. The run surfaces these with a recovery hint: rate limited resolves by waiting; quota exceeded means the provider account itself needs attention — ask an administrator to check the plan or billing; context too large means switch to a bigger-context model or start the work fresh. A brand-new organization hitting credential errors on its first run almost always has a mistyped provider key — keys are not validated when saved.