Run Lifecycle and Statuses
Every execution of an automation is a run — a durable record you can inspect in the run history of the automation. This page explains what each status means, how a run moves through its lifecycle, what happens when things go wrong, and how the platform recovers runs stranded by a crash.
Automations (agentic orchestration) are enabled per tenant by StackJack on request. If you don't see the Automations area in your portal, contact StackJack support.
What a run record contains
For every run you can see:
| Field | Meaning |
|---|---|
| Status | The lifecycle state (see table below) |
| Summary | The agent's last message, truncated to 2,000 characters |
| Error message | Explanation for a non-successful outcome, when applicable |
| Token usage | Input, output, cache-read, and cache-write token counts |
| Active seconds | Actual model compute time (not wall-clock time) |
| Tool calls | Number of tool calls the agent made |
| Credits consumed | What the run cost you (0 for BYOK and StackJack-initiated runs) |
| Timestamps | Created, started, completed |
| Trigger | How the run started: on-demand, scheduled, or webhook |
| Version | The exact automation version (configuration snapshot) that executed is recorded on every run for audit attribution. It is not currently displayed on the run page — contact StackJack support if you need the exact configuration a past run used. |
Full turn-by-turn transcripts are fetched on demand from Anthropic when you open the transcript viewer — StackJack never stores transcript content itself.
Run statuses
| Status | Terminal? | What it means |
|---|---|---|
| Pending | No | The run row exists, but the agent session hasn't started yet (credit reservation and session setup are in progress). |
| Running | No | The agent is actively working. You can watch live output and stop the run. |
| Completed | Yes | The agent finished its turn normally. Also used when the agent stopped because it reached its own turn or budget limit — the error message will say so (for example, "Stopped: max budget reached"). |
| Failed | Yes | Something went wrong: the upstream model service exhausted retries, the session was terminated, the run required a tool approval (see below), or the platform recovered a crashed run. The error message explains the cause. |
| TimedOut | Yes | The run hit the automation's configured runtime cap. The agent is asked to wrap up and summarize before the run ends. |
| CreditExhausted | Yes | Either the run couldn't start because your balance was insufficient (the error message shows required vs. available credits, and nothing is charged), or the run hit its per-run credit cap mid-flight (the agent is asked to wrap up first). |
| Interrupted | Yes | You (or a StackJack operator) stopped the run. A stop reason is recorded on the run (portal stops are recorded as user-requested). |
| AwaitingInput | No | Reserved for human-in-the-loop approvals. Not currently in use — see below. |
| Skipped | Yes | A scheduled run was dropped before it started because every shared execution slot was busy when its schedule fired. Nothing is reserved or billed, and the reason is recorded in the run's summary. It is a capacity outcome, not a failure. |
How a run starts
When a run is triggered (manually, on schedule, via webhook, or from a connected AI assistant):
- Eligibility checks. The automation must be active, not archived, have accepted consent, and be fully provisioned and in sync. Your tenant must have automations enabled.
- Execution slot. The run claims one of the platform's shared execution slots. If all slots are busy, the trigger is rejected or skipped rather than queued — see Triggers and execution guarantees. A scheduled trigger skipped this way is recorded as a Skipped run so the drop stays visible in your history.
- Credit reservation. For metered (non-BYOK) tenants, credits are reserved up front — the lesser of a runtime-based estimate and the automation's per-run credit cap. If your balance can't cover the reservation, the run is recorded as CreditExhausted with the required and available amounts, and nothing is charged.
- Session start. An agent session is created and the run transitions Pending → Running. Live output streams to the portal.
How a run ends
The run monitor watches the agent session and applies the first terminal outcome that occurs:
- Agent finishes →
Completed. - Agent hits its own turn/budget limit →
Completed, with a warning in the error message. - Runtime cap reached → the agent receives a "wrap up and summarize" message, then the run is marked
TimedOut. - Per-run credit cap reached → same wrap-up message, then
CreditExhausted. Usage above the cap is never billed to you — the platform absorbs any overage. - Model-side failure (retries exhausted, session terminated) →
Failed. - You stop the run →
Interrupted.
After the stream ends, final token usage and active seconds are re-fetched authoritatively from Anthropic, so billed usage matches what actually ran.
Status transitions are strictly ordered — once a run reaches a terminal status, nothing can overwrite it and its recorded outcome is final.
Stopping a run
You can stop a run that is Running from the run detail page.
- Open the running automation's run detail page (the live output panel is at the top).
- Click Interrupt. There is no confirmation dialog or reason prompt — the stop takes effect immediately, and the reason is recorded as user-requested.
- The run is immediately marked Interrupted, the live monitor is cancelled, and the agent is signaled to break off its current turn.
Billing for an interrupted run reflects actual usage up to the stop point; the unused portion of the credit reservation is refunded automatically. Stopping a run that has already finished is rejected — the run's recorded outcome never changes after it reaches a terminal status.
Human-in-the-loop approvals (not yet available)
Agents must currently be configured to auto-allow their tools. If an agent pauses to ask for a tool approval, the run ends as Failed with a message telling you to adjust the agent's tool policy to auto-allow.
Human-in-the-loop approvals — where a paused run waits for you to approve or deny a tool call from the portal — are coming soon. When they ship, the AwaitingInput status will become active and paused runs will show a "needs approval" action instead of failing.
Crash recovery: what you may observe
StackJack automatically recovers any run stranded by a restart or crash, so no run stays Running or Pending forever. If that happens to one of your runs, you'll see:
- The run flips to Failed with an error message explaining it did not complete within the platform's time limit.
- Reserved credits are refunded automatically — you don't need to open a ticket. The refund typically appears within minutes of the run being recovered (you'll see it in your credit transaction history).
Lost refunds are recovered the same way, so a failed run never silently keeps your reservation.