Skip to main content
A session has two states: active and stopped. It leaves active in exactly three ways: you stop it, its timeout expires, or (WebSocket connections only) the socket disconnects.

Stopping a session

Stopping is an update, not a delete, and it cannot be undone.
There is no POST /browsers/{id}/stop endpoint. If you’re getting a 404 on a stop call, this is why. Stop sessions as soon as you’re done with them. Browser time is billed at $0.02/hour until the session stops or times out, whichever comes first.

Disconnecting vs stopping

The two connection styles behave differently when your client goes away: The SDK behavior is what lets you disconnect and reconnect to the same session, but it also means forgotten sessions keep billing. If you see 429 Too many concurrent active sessions, list and stop the strays:

Timeouts

Every session has a lifetime set at creation: timeout in minutes, default 60, maximum 240 (4 hours). The expiry moment comes back as timeoutAt in the session object. A timed-out session stops automatically and cannot be extended or reused, so if a workflow might outlive the default, set the timeout up front:

Inspecting sessions

The session object carries the operational fields: status, timeoutAt, startedAt, finishedAt, live and CDP URLs, plus cost tracking (browserCost, proxyCost, proxyUsedMb).

Recordings and downloads

  • Create the session with enableRecording: true and recordingUrl is populated after the session stops. It is null while the session runs and shortly after stopping while the video is processed.
  • Files downloaded by the browser during the session are listed at GET /browsers/{session_id}/downloads.