Run Detail: Live Stream, Interrupt, and Transcripts

The run detail page is the forensic view of a single run — and, while the run is still going, your live control panel. You land here automatically when you click Run now on an automation, or open any row in Run History.

The header and key facts

The header shows the run's short id, a status badge, the trigger, and when it started.

Below it, a Key facts grid gives the numbers you scan first:

• Duration — how long the run took (its metered active time when available, otherwise the wall-clock span).
• Tool calls — how many tools the run invoked.
• Credits — credits consumed, shown to two decimal places. On a run that used your own Anthropic key this tile is replaced by Est. API cost — a dollar estimate on your Anthropic key, priced from the run's recorded tokens at the list rates of the model the run actually ran on. Session runtime is excluded (it is StackJack infrastructure, not Anthropic usage), and cache writes are priced at the 5-minute cache rate, so a longer-lived cache costs somewhat more than shown.
• Tokens — every token class the run used, added together (input, output, cache reads, and cache writes), with an in · out · cached sub-line; hover for the four exact numbers.

A couple of context notes can appear here too: if StackJack staff started the run on your behalf, an info note says so and that no credits were charged to your account; if the run was automatically restarted after a service interruption, a line notes that StackJack reuses the original credit hold when one exists and keys final settlement to the run. BYOK runs bypass that ledger, and both the stranded Anthropic attempt and the fresh replacement may incur usage charged directly to your Anthropic account.

While a run is still in progress the page updates itself — the status badge, the key facts, and (once the run finishes) the summary all refresh on their own, so you don't have to reload the page or navigate away to see the final outcome.

Cost breakdown

Under the key facts, a Cost breakdown card explains why the run cost what it did. The single Credits number is hard to reconcile on its own, because the biggest contributor is almost always cache reads — invisible until you open this card.

The table gives each class its token count and its share of the credits, then two totals:

Shares are recalculated from the automation's current model and current rates. The Billed row is the authoritative final recorded charge once settlement completes; use it for billing questions, especially after a model or price change. While a run is non-terminal, usage and credits are partial. A recently terminalized or recovered run can also briefly await settlement, so refresh before treating a zero as final.

When Raw total and Billed disagree, the card explains which of four reasons applies:

• No StackJack credit charge is recorded — expected for BYOK, a staff-initiated run, or a run that ended before billable model work. For a just-terminalized or recovered run, first confirm settlement is final.
• Billed is exactly the cap and raw is higher — StackJack limited this run's charge to the automation's Max credits per run cap, and the difference was not charged to you. This is rare: a run is normally charged for all the credits it used, including the model turn that crossed the cap, so its bill can sit slightly above the cap.
• The run was restarted — Billed includes the credits of an earlier attempt of the same run that stopped before it finished, and the breakdown prices this attempt only.
• Any other difference — the billed figure is what was charged when the run finished; the breakdown is recalculated at today's rates, so it differs, in either direction, if pricing or the automation's model changed since.

The card is skipped entirely when the automation's configuration cannot be loaded — credit rates are per model, and showing nothing is better than guessing one.

Tool sequence

When a run has made (or, in a dry run, would have made) tool calls, a Tool sequence card lists them in the order they ran. Select one or more and choose Allow, Require, or Deny to add them to this automation's tool policy, or To chain to capture them as an ordered chain — each opens the advanced builder with your selection staged.

The card prefers StackJack's durable tool-call rows. For older or still-running runs it can fall back to the live event stream or transcript. That means the card can remain useful even when an Anthropic transcript is unavailable.

Summary, errors, and timing

• Summary — when the agent produced a final summary of what it did, it appears in its own card.
• Error — if the run recorded an error, it is shown in a red banner (a failed run says it "failed"; a run that merely reported an error says so).
• Timing — a card near the bottom lists when the run was Created, Started, and Completed, plus Active time (the time the AI session was actually working, which also feeds runtime billing).
• Trigger payload — shown when the run was started with input: your Run with message… text, an AI-assistant-supplied message, or the (filtered) body of a webhook delivery.

If a trigger payload is present, Re-run with this payload starts a new manual run using that payload — or a queued one, if every slot is busy. The new run gets its own run id and credit reservation; the original run and its evidence are unchanged.

Completed runs with warnings

A run can finish its core work while still surfacing guardrail evidence:

• Required tool not used (SJ-RUN-REQUIRED-TOOL-SKIPPED) — a tool marked Require was not called. This is a warning, not a failed-run status.
• Tool chain contract not met (SJ-RUN-CHAIN-VIOLATION) — at least one callable tool required by a Required or Ordered chain was not called. The terminal status becomes Completed with violations.
• Post-step checks (SJ-RUN-POSTCONDITION) — one or more configured postconditions failed, could not be read, or were not checked. The card identifies which case occurred.

Read these warnings alongside the durable Tool sequence. A green or amber terminal state is not proof that every required step and check succeeded.

Watching a running run (live stream)

While a run's status is Running, a Live stream card appears:

1. The stream starts on its own when you open a running run — you don't have to click anything to begin watching. (This holds even if you arrive while the run is still queued: it starts streaming the moment the run flips to Running.)
2. Events render as a live conversation timeline — the same view as the transcript below: assistant and user turns, collapsible thinking blocks, and each tool call paired with its result as a collapsible card marked ok or error.
3. Click Pause to stop consuming the stream (the run itself keeps going); Start stream resumes watching.

Interrupting a run

The Interrupt button (in the Live stream card) stops a running run:

• The run is durably marked Interrupted first, then the execution is cancelled — an interrupt is never silently lost.
• Credits are settled from actual usage: whatever portion of the run's credit reservation went unused is refunded.
• Interrupted runs stay in run history with their status and usage intact.

Cancelling before execution

A run shown as Queued has not started an AI session and has no credit reservation. Its card offers Cancel rather than Interrupt. Cancelling marks the run Interrupted, removes it from the durable queue, and consumes no credits.

Paused runs and tool approvals

Supervised dry-run tests can pause in Awaiting input before executing a captured tool call. The page shows the tool, its change classification, and either parsed arguments or raw JSON. Review them carefully:

• Approve & run resumes the paused run, and the connector call executes for real against your live systems. A supervised test run is still a test run, but the approved call is not simulated. Your approval releases the next destructive call of that tool, on this automation's identity — it is not matched against the run id or against the arguments displayed here, so avoid running a second copy of the same automation while an approval is open. A destructive tool additionally requires this automation's destructive-action acknowledgment; without it, StackJack still blocks the call after you approve it. Review the tool and its arguments before you click, and check the change in the target system afterwards. See Approving a supervised test call.
• An approval can be refused if your organization is at its concurrency limit. Resuming needs a free execution slot like any launch. If none is free, the decision is not applied — the run stays Awaiting input with nothing sent to the model and no tool call made, and you are told to try again shortly. The 60-minute deadline below keeps running while you wait, so free a slot (or interrupt another run) rather than retrying blindly. See Concurrency, Slots, and the Run Queue.
• Deny keeps the tool call from running; you may add a reason for the agent.
• Cancel run stops the paused run now, after you confirm. The tool call it is waiting on does not run, anything the run already did is not undone, and the run is charged for what it already used. If the stop is refused, the page shows why, and the run's status on the page is its real one.
• If nobody decides within 60 minutes, cleanup tries to stop and confirm the provider session. A confirmed stop lets the run end as Failed with actual usage billed and the unused reservation refunded. If StackJack cannot confirm the stop, the run remains Awaiting input and cleanup retries instead of reporting a false failure. A run whose approvals were repeatedly refused for want of a slot can reach that deadline with the tool call still not taken.

If StackJack could not capture the pending tool-use id, the run is not safely approvable. The page offers Cancel run and tells you to retry or contact support instead of presenting controls that cannot resume the right call.

Production runs do not pause for approval: a run that hits a required approval outside a supervised test ends as Failed instead. See Guardrails and Safety.

Transcripts

If the run has an Anthropic session id, a Transcript card appears at the bottom.

Storage boundary: Anthropic preserves the full session transcript, which can contain customer data from tool calls. StackJack does not copy that complete conversation or full tool-result bodies into its database in your region. It does retain the filtered trigger payload, Anthropic session id and key provenance, summary and error text, usage and cost, and pending tool input while an approval is required.

On the normal run-monitor path, terminal finalization attempts to fetch and walk the authoritative Anthropic transcript before the session is archived. It stores a limited tool-call projection for the durable Tool sequence: call order, tool name, connector prefix, read-only/destructive classification, terminal classification, invocation time when present, and the call's input arguments as capped JSON. Tool-result bodies, assistant/user conversation text, and thinking blocks are not persisted by that capture.

That record is not guaranteed for every run. A run that ends early, for example after a direct interrupt, can have no tool-call record; requesting its tool calls then reads them from Anthropic once. If Anthropic can no longer return the events, the remaining durable run metadata is all StackJack can show.

The full conversation remains at Anthropic and is fetched for the Portal when you ask to view it. The Portal does not render or request the full conversation view before that action. Because normal terminal capture and lazy tool-sequence backfill can read transcript events separately, however, clicking View transcript is not necessarily the first time StackJack has read those events.

1. Click View transcript. The full conversation is fetched on demand from Anthropic and rendered as a timeline.
2. The timeline shows assistant and user turns, collapsible thinking blocks, and each tool call paired with its result as a collapsible card marked ok or error. Expand a tool call to see its arguments and result, each with a copy button. A Conversation / Raw JSON toggle switches to the raw event stream, and Download saves the raw JSON.
3. Long transcripts are windowed — Show more reveals the next 250 events, and Load more events fetches the next page from Anthropic when one exists.
4. Click Refresh to re-fetch (useful right after a run completes).

If the fetch fails you'll see one of: SJ-TRANSCRIPT-FORBIDDEN (access denied), SJ-TRANSCRIPT-NOT-FOUND, SJ-TRANSCRIPT-UNAVAILABLE (couldn't reach the automation service), or SJ-TRANSCRIPT-ERROR (other failure). Use the durable status, tool sequence, summary, warnings, and usage as the operational record when the remote transcript cannot be fetched.

If the message says your Agent Runner plan has ended, the fetch is not failing — your own Anthropic key is no longer being used, and fetching a transcript needs it. Restore the plan to read this run's transcript. Removing the key sends new runs back to credits, but it does not make this transcript fetchable: the fetch uses whichever key is on file at the moment you ask, and this session was created in your own Anthropic workspace. Contact support if you need a historical session investigated. See When an Agent Runner plan ends. The same applies to the Tool sequence card when it has to backfill its rows from Anthropic.

Deleting this run's transcript

Owners and administrators see a Delete transcript button in the header of a finished run. It deletes the conversation, the run's input and final answer, and the tool inputs, from StackJack and from our AI provider, and keeps the run record. A banner under the header then shows whether the deletion is scheduled, done, or could not finish everywhere, and once it is done the Transcript card, the input and the summary say the content was deleted with the transcript. See Deleting run transcripts.

Page-load errors

SJ-AGENT-FORBIDDEN (your tenant may not view this run), SJ-RUN-NOT-FOUND (the run does not exist), SJ-AGENT-UNAVAILABLE (transient — retry), SJ-AGENT-SERVER-ERROR (retry, then contact support).