Skip to documentation

Operations

Runs and evidence

Follow job state, usage, blockers, and verified GitHub outcomes.

Workspace and repository views

The workspace Runs page shows recent jobs across connected repositories. Each repository also has a focused Runs tab. Open a run to inspect its attempt, status, events, token usage, failure reason, and artifact evidence.

Read status honestly

If the workspace runner is offline, active-looking jobs are not presented as healthy ongoing work without a recent heartbeat.

  • Queued: eligible and waiting for a connected runner and capacity.
  • Running: claimed by a runner with an active lease.
  • Succeeded: the expected outcome was verified.
  • Needs attention: blocked, failed, interrupted, or awaiting operator judgment.

Inspect the outcome

Evidence can include branches, commits, pull requests, reviews, issues, validation results, token telemetry, and precise blockers. Artifact markers make retries idempotent and let the runner verify the expected GitHub result.

Inspect status, events, usage, and the GitHub artifact attached to a run.
Read transcript

The demo opens workspace Runs, selects a completed job, reviews the event timeline and token usage, and follows the verified GitHub artifact link.

Frequently asked questions

What makes a run successful?

The expected artifact contract must be satisfied and verified, not merely described in model output.

Where is token usage recorded?

Sanitized token telemetry is attached to run events and summaries when reported by the runner.

Can retries create duplicate artifacts?

Artifact markers and verification are designed to make retries idempotent and detect existing outcomes.

Why does a run need attention?

Open it to inspect the exact blocker, failure, runner interruption, configuration problem, or missing outcome.