Anchor Browser sessions are observable at every stage: watch a session live while it runs, replay the video after it ends, and pull structured logs and page-state snapshots through the API. This page is the map of those surfaces and when to reach for each one.

Watch a session while it runs

Every session returns a live_view_url at creation. Open it to watch the browser in real time, or embed it in your own product as an iframe. The view is interactive by default, so an operator can take over mid-run; add pointer-events: none for a read-only window. One-time URLs invalidate after the first viewer disconnects, which keeps shared debugging links from outliving the incident.

Live view is also the handoff surface for human-in-the-loop interventions: when an agent pauses and asks for help, the live view is where a person supplies it.

Replay a session after it ends

Sessions record to MP4 by default. Each completed session links to its recording in the session history dashboard; while a session is still running, the same link opens the live view instead.

Programmatically, recordings are managed per session:

• List recordings: sessions.recordings.list(sessionId)

• Fetch the primary recording: sessions.recordings.primary.get(sessionId)

• Delete a recording: sessions.recordings.delete(sessionId, recordingId)

Recording can be paused and resumed mid-session, which keeps screens with sensitive data off video while the rest of the run stays replayable. For workloads where nothing may persist, zero-data-retention mode disables video and log recording entirely; observability then comes from the live view during the run and your own application-side logging.

Pull the structured logs

Three log streams are captured per session and exposed through the API:

• Agent logs: the in-session AI agent's log lines, for tracing what the agent attempted and why a task ended the way it did.

• Browser-action logs: the browser-level actions performed during the session.

• Network-response logs: the network responses observed during the session, for diagnosing failures that originate server-side.

For task and tool runs, execution logs return the structured entries captured during a specific execution, execution page states return the captured page-state snapshots for stepping through what the page looked like as the run progressed, and execution artifacts list and download the files a run produced.

Note that sensitive data masking applies across these surfaces, and secret values are excluded from logs and telemetry by design, so credential material does not leak into your debugging trail.

How long recordings and logs are kept

Retention follows the plan. The pricing page sets data retention at 45 days on the Free and Starter plans, with custom retention on Growth and Enterprise. For workloads that may keep nothing at all, zero-data-retention mode turns off video and log recording for the session entirely.

Wire events into your own systems

Webhooks deliver real-time notifications when tasks, sessions, and identities change state, with HMAC-SHA256 signature verification, a delivery history per webhook for auditing what fired, and synthetic test events for exercising the path before production. This is the integration point for paging, retry orchestration, and run-state dashboards on your side.

Debug at fleet scale

Single-session tools stop being enough somewhere around the tenth concurrent run. For fleets:

• Session tags label sessions with custom keys (workflow name, customer, environment) so you can find the one run that matters.

• Sessions history returns usage analytics for the team, and the paginated session list walks every session with its status.

• All-sessions status answers "what is running right now," and per-session status drills into one.

• Batch session status tracks grouped runs, with retry of failed sessions built in.

• Tool stats aggregate execution outcomes per tool, which is the first place a reliability regression shows up.

A debugging sequence that works

1. Find the run. Filter by session tag or walk the session history.

2. Watch it. Still running: open the live view. Finished: pull the recording.

3. Read the agent's account. Agent logs say what it tried; page states show what it saw.

4. Check the wire. Network-response logs separate "the site failed" from "the automation failed."

5. Fix and re-run. Natural-language tasks update via an edit instruction; failed batch sessions retry in place.

More observability surfaces

Anchor also supports the deeper debugging surfaces teams reach for when a video and the structured logs leave a question open:

• Console-log capture for reading a session's browser console output.

• Request-level network detail and HAR export for inspecting headers, payloads, and timing beyond the response stream.

• DOM-level replay for stepping through inspectable page elements at each point in a run, alongside the MP4 video and page-state snapshots.

• Cross-session log search for querying logs across many sessions rather than one at a time.

• Alerting and metrics for failure-rate thresholds and monitoring feeds, on top of the webhook eventing above.