Run diagnostics

The run page presents one chronological source through three customer-facing views.

Details

Use Details to answer:

• Did requested work complete?
• When did the run start and finish?
• Which deployment version ran?
• Which entrypoint, region and machine were used?
• Is the workspace saved or updating?
• Did turns complete before later cleanup stopped the run?
• Is a runtime update recommended?

Details intentionally omits internal identifiers and infrastructure provenance that do not help the customer act.

Activity

Use Activity for the important lifecycle:

• run admission and start;
• sandbox initialization and readiness;
• run and turn transitions;
• tool and artifact events;
• workspace checkpoint and upgrade events;
• compaction and active-tool changes;
• warnings, errors and cancellation.

Activity is a readable projection, not a second event store.

Diagnostics

Use Diagnostics for the complete sanitized technical stream. It retains lower-level runtime evidence and stable event names needed for support and automation.

Diagnostics never exposes:

• credentials or authorization headers;
• provider payload contents by default;
• private storage or encryption metadata;
• platform control credentials or connection details;
• raw tool arguments or results;
• platform-owned runtime files.

Diagnostic workflow

1. Read the interpreted outcome in Details.
2. Find the last successful lifecycle transition in Activity.
3. Open Diagnostics near the same timestamp.
4. Identify the failure phase.
5. Apply the troubleshooting guide for that phase.

Common phases

admission
  -> deployment
  -> sandbox
  -> worker
  -> provider
  -> tools and extensions
  -> checkpoint
  -> cancellation and cleanup

Do not diagnose a run from its final state alone. Compare run, turn, sandbox, and workspace evidence.