How We Built Session Recording Into Browser Cloud From Day One - Not as an Afterthought

When an agent fails mid-task, you get a stack trace and nothing else.

No context. No replay. No way to understand what the agent actually witnessed at the moment it went wrong. This is the default behaviour of most browser infrastructure built for execution, not observability. For human-paced testing, that's fine, you can reproduce manually and re-run. AI agents don't work that way.

Most teams that hit this wall solve it the same way: add a screen recorder to the runner, pipe logs to S3, stitch things together manually. It works until it doesn't. The recorder runs in a separate process. It captures the screen but misses network events.

Logs exist, but aren't synchronized with the visual timeline. When the agent fails on step 7 of a 12-step workflow, you're correlating timestamps across three tools to understand whether it was a rendering delay, a CAPTCHA intercept, or a bad selector.

As a result, you end up debugging the debugging setup.

What Browser Cloud Offers

Every Browser Cloud session automatically captures four things, in sync:

• Video recording of everything that executed inside the browser window, such as page loads, clicks and DOM transitions.
• Console logs, every JavaScript exception and error the page emitted, are mapped to the exact moment in the timeline.
• Network logs showing every request the browser made, with status codes and response times.
• Command replay of every action your agent issued, annotated on the same timeline as the video.

These four streams are indexed to a shared session clock. Jumping to the failure moment in the video shows the network request it triggered, the console error it produced, and the agent command that caused it, in the same view.

This works because the recording isn't added to the session; it's part of how the session is constructed. When you call sessions.create(), the session owns the browser lifecycle, the network layer, and the recording pipeline together. The recorder doesn't infer context from the outside. It's already inside.

const session = await sessions.create();
// Recording starts automatically - video, console, network, commands.
await session.release();
// All four streams available immediately. Nothing to configure.

At scale, this means 50 concurrent sessions produce 50 independent, synchronized recordings and not 50 video files and a shared log stream you have to split manually.

Watch, troubleshoot and replay your agent's browser sessions with this documentation.

What Changes for Your AI Agents

The first time an agent fails in production, the difference is obvious.

Without session recording: check the error log, reproduce locally, add instrumentation, re-run, and hope it reproduces. With Browser Cloud: open the session replay, scrub to the failure timestamp, and see exactly what the agent saw. Done in minutes instead of hours.

Teams running Browser Cloud for production workflows have caught things that would have been invisible otherwise - CAPTCHAs that only appeared for certain IP ranges, login flows that broke silently on specific screen sizes, API responses returning 200 with error payloads the agent was treating as success. None of these surface in a stack trace.

AI agents operating on the real web are non-deterministic. Pages change, auth flows break, and state drifts between sessions. In that environment, observability isn't optional.

Building recording as part of the session object means the data is always there, always synchronized, always complete. When your agent fails, and it will, you should understand exactly why in minutes.

Run your first session on Browser Cloud now!