Automation goes wrong in ways a log never captures: a consent dialog nobody expected, a challenge page that only appears on one identity, a login that reports success onto a page that is still signed out. Live View streams the frames of a session that is running right now - on your server, in a container, or on a machine you are nowhere near - into a tab in your dashboard.
Four hops, no local agent on either end, and nothing written to disk along the way.
Frames come from the browser engine's own screencast, over the debugging protocol the SDK is already connected to. It is not a screenshot loop and not a second browser rendering a copy - it is what that session actually painted.
Each session gets its own relay instance and its own token. The first connection fixes that token; anything presenting a different one is refused, so a session key on its own is not enough to watch someone's browser.
The relay forwards frames between the running browser and whoever is watching, and keeps nothing. No recording is written, and the session is torn down 60 seconds after the last connection drops.
The viewer is a page in your dashboard. There is nothing to install, no VNC or RDP on the host, and no port to expose from the machine the browser runs on.
It is view-only, deliberately. Clicks and keystrokes are not sent back to the session - watching cannot change what the run does, so a tab left open on a second monitor can never become the reason an automation behaved differently. If you need to drive the browser by hand, open that profile in the desktop app instead; it is the same profile, the same identity and the same cookie jar.
| An automation that only fails on one identity | Watch that profile run while the other twenty keep going. What appeared on screen is usually the answer, and it never reaches a log file. |
| A challenge page you cannot reproduce locally | The run that gets challenged is the run you watch, on its own exit IP, instead of trying to provoke it again on your own machine. |
| A login that claims to have worked | A script reporting success and a site actually being logged in are two different facts. One of them you can see. |
| A browser that has no screen at all | Sessions on a server, in a container, or on a machine you are not sitting at. There is nothing to VNC into and nothing to install on the host. |
Live View is on every paid plan, from Basic up. It is opt-in per launch, so a session is never streamed unless you asked for it.
Pass liveView: true when you launch. That registers the session and starts the stream; leave it out and the browser runs exactly as before, with nothing to watch and nothing encoded.
Streaming sessions appear in the dashboard's session list with a Live View link. Opening it connects to that session and starts drawing frames; closing the tab stops your side of the stream.
The Live View endpoints answer a free-plan key with a 403 rather than quietly returning nothing, so it fails loudly instead of looking broken. Everything else about the session is unaffected.
Plans and limits are on the pricing page. If you are already on a paid plan, your running sessions are in the dashboard.
No. Clicks and keystrokes are not sent back to the session, by design - watching a run can never become the reason it behaved differently. To drive the browser by hand, open the same profile in the desktop app: same identity, same cookies.
That is the case it exists for. Frames come from the engine itself rather than from a desktop being captured, so there is nothing to VNC into, nothing to install on the host and no port to expose from it.
No. The relay forwards frames between the running browser and whoever is watching and keeps nothing, and the session is torn down 60 seconds after the last connection drops. If you need a recording, capture it yourself on your side.
Each session carries its own token, fixed by the first connection; anything presenting a different one is refused. A session key on its own is not enough to watch a browser.
Frames are JPEG at quality 60, capped at 1280x720, and only every second frame is sent. Those are defaults you can change per launch. Nothing is encoded at all unless you asked for Live View on that launch.
Yes. A session launched over MCP streams the same way as one launched from the SDK, which is usually the only way to see what an agent is doing on a page.