Monitor runs and respond safely

Use Live runs to find out what a workload is doing, investigate a failure, or follow a queued result. A run is one execution of a workload. Recovery can create more work, so inspect the run before taking action.

Before you start

Select the workspace that owns the run. You need permission to view executions. Running a retry, controlling a workload, and deciding a protected human request require separate permissions. Ask your workspace administrator for the specific task you need if an action is unavailable.

Find and inspect a run

1. Open Monitor → Live runs.
2. Use the status filter to narrow the Run stream. Check the workload, current step, age, token use, cost, and status. Unknown or unavailable cost means the information is missing; it does not mean zero usage.
3. Select the row or Inspect run. Confirm the run’s workload, actor, release, and start time before investigating.
4. In Story, read the outcome explanation and select a step in Step timeline. Review the evidence attributed to that step. If attribution is ambiguous, use the run’s Evidence tab instead of assuming that an artifact belongs to the selected step.
5. Use Graph for recorded relationships, Cost for usage details, Subagents for child work, and Provenance for available execution provenance. Follow a child run to inspect its own outcome.

The result is a view of the recorded execution and the evidence you may access. It is not a transcript of private model reasoning. Partial, redacted, expired, or missing evidence limits what you can conclude. If an export is unavailable because required evidence is incomplete, resolve the evidence gap with the workload owner.

Retry a finished run

Use a retry after you understand why the run failed and whether its earlier actions already affected another system.

1. Open the run’s Story tab and find Act.
2. Read any recovery notice, including committed effects and their delivery state. If recovery needs operator review, is denied, or the checkpoint cannot be verified, give the run reference and notice to your platform operator.
3. If Retry this run is available, select it and read the confirmation.
4. Select Retry to dispatch a new run from the start, in the original run’s environment. Check the resulting run in Live runs.

The original run remains unchanged. A retry is a fresh governed attempt; it does not resume at the failed step or undo an earlier external action. The release is resolved again rather than frozen to the original run. A new run can therefore use a newer eligible release. Review the current release with its owner when that matters.

If a request fails or its result is unclear, refresh and check for a newly dispatched run before trying again. Do not use repeated retries to bypass a governance denial. Fail over to backup route is unavailable; this screen cannot switch a run’s provider.

Pause or resume a workload

In Story → Act, Pause and Resume workload act on the whole workload, not only the run you are viewing.

• Pause asks in-flight runs to pause at their next step and newly dispatched runs to pause before doing work. Dispatch itself remains possible. The signal lasts up to one hour unless reapplied.
• Resume workload clears that signal early. A success message confirms that the signal was sent; continue monitoring runs to see their progress.

These controls do not undo work, approve human requests, or create a durable prohibition on execution. For an incident that needs a persistent fence, contact the operator responsible for Containment. See governance and audit tasks for the distinction.

Decide a protected human request

If Story → Act shows Governed human decision, inspect the request before selecting Approve or Deny.

1. Confirm whether it concerns Execution admission or a Serial acting call.
2. For execution admission, an authorized workspace oversight manager can decide the request. For a serial acting call, the human identity bound to that exact call must decide it. Management access alone does not make another person the bound human.
3. Use a recent verified human session and the required human oversight permission. If either is missing, follow the access or sign-in guidance; do not ask someone else to impersonate the bound person.
4. Select Approve or Deny once. Review the recorded decision and, when available, Open governed continuation to follow the resulting attempt.

Approval can queue a fresh governed attempt; it does not guarantee that the attempt will succeed. Denial dispatches no continuation. If authority changed or a decision became stale, refresh and review the current request before acting.

An approval required outcome without a protected decision may belong to the source application. Complete that business decision in the application that requested it. Resume workload does not approve it. The separate Human oversight records describe oversight arrangements and recorded events; they are not a replacement for this protected decision.

When the page does not answer your question

If no runs appear, confirm the workspace, clear the status filter, and check that a run was actually dispatched. A degraded timeline means live updates could not be read reliably; refresh before relying on the latest state. If evidence or analysis fails to load, use the page’s retry action and share the run reference, visible error, and approximate time with support. Never include secrets or sensitive input in a support message.

Continue with using an app, operating a release, or reviewing governance evidence.