> ## Documentation Index
> Fetch the complete documentation index at: https://docs-preview.webcompute.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Observe and debug

> Inspect browser-agent runs with live sessions, recordings, artifacts, status, events, blockers, and errors.

Browser agents fail in ways text-only agents do not: blocked pages, unexpected dialogs, changed layouts, downloads, redirects, auth walls, and slow pages. Webcompute keeps the run inspectable.

<img src="https://mintcdn.com/web-634f5865/kMyXyr8xUcQ6rZfT/images/product/debug-ui-apple.png?fit=max&auto=format&n=kMyXyr8xUcQ6rZfT&q=85&s=6c06918b6a193cf31211666da325fd66" alt="Webcompute Debug UI showing a live browser on Apple's Mac mini page with network events and the recording timeline visible" width="1800" height="1199" data-path="images/product/debug-ui-apple.png" />

The Debug UI gives operators a live browser view plus browser status, page metadata, recording state, event timeline, inspector panels, and browser-moment sharing. When recording is enabled, the same surface can replay captured browser frames after the run moves on or closes.

## Debug UI anatomy

| Area                  | What it answers                                                                           |
| --------------------- | ----------------------------------------------------------------------------------------- |
| Live browser viewport | What page is the browser actually showing now?                                            |
| Active page metadata  | Which URL, title, and page ID is Webcompute operating on?                                 |
| Runtime readiness     | Is the browser ready, configuring, recovering, stopped, or blocked?                       |
| Recording state       | Is replay evidence being captured for later review?                                       |
| Event timeline        | What navigation, action, download, dialog, blocker, or error happened over time?          |
| Inspector panels      | Which status, artifacts, downloads, dialogs, pages, or capabilities can you inspect next? |
| Share controls        | How do you hand this exact browser moment to a teammate, reviewer, or agent?              |

Use Debug UI when the live browser state matters. Share a browser moment when another person or agent needs the same page state and timestamp. Use recordings when the run has already moved on or closed. Use artifacts and downloads when the workflow produced files that another system needs to review.

## What you can inspect

<Columns cols={2}>
  <Card title="Live browser sessions" icon="monitor" href="/observe-and-debug/live-browser-sessions">
    Open a live Debug UI and share exact browser moments with humans or agents.
  </Card>

  <Card title="Recordings" icon="video" href="/observe-and-debug/recordings">
    Replay what happened after the run.
  </Card>

  <Card title="Artifacts and downloads" icon="download" href="/observe-and-debug/artifacts-and-downloads">
    Capture files, reports, PDFs, and evidence.
  </Card>

  <Card title="Status, events, and logs" icon="list-tree" href="/observe-and-debug/status-events-and-logs">
    Connect browser state and timeline evidence to application logs.
  </Card>

  <Card title="Blockers and CAPTCHA" icon="octagon-alert" href="/observe-and-debug/blockers-and-captcha">
    Return clear blocker state instead of pretending success.
  </Card>
</Columns>

## Typical debug loop

<Steps>
  <Step title="Check the result status">
    Start with `completed`, `blocked`, `needs_confirmation`, `failed`, or `cancelled`.
  </Step>

  <Step title="Read the step summaries">
    Look at page titles, URLs, observations, and errors from the browser steps.
  </Step>

  <Step title="Open evidence">
    Use Debug UI for live inspection, browser-moment sharing for handoffs, recordings for replay, and artifacts for downloaded files.
  </Step>

  <Step title="Tighten the workflow">
    Add domain policy, structured output, approvals, timeouts, or deterministic checks where the run was ambiguous.
  </Step>
</Steps>

## What to keep with the job

Store enough evidence to explain the outcome without leaking credentials:

* Job ID and browser ID.
* Result status.
* Final page URL and title.
* Bounded observation metadata.
* Artifact, download, file, or recording IDs.
* Redacted error `code`, `name`, and `message`.
* Blocker or CAPTCHA state when present.

Do not store signed Debug UI URLs, signed CDP URLs, raw provider keys, cookies, or full page observations in shared logs.

<Warning>
  Treat signed Debug UI and CDP URLs as bearer credentials.
</Warning>

Reference: [results and evidence](/observe-and-debug/results-and-evidence), [production observability](/production/observability), and [errors](/observe-and-debug/errors).