lupin.Open console
Browsers

Separate browser timeouts and deadlines

Distinguish action deadlines, access-link startup expiry, inactivity and runtime leases when diagnosing browser failures.

Lupin editorialAI-assisted3 min read

Start by identifying the expired clock

A browser workflow has several clocks, and each controls a different failure mode. A page action has a bounded execution window; a connection link has a deadline for starting access; the provider has an inactivity timeout; and billing-enforced workspaces reserve a finite runtime lease. An HTTP client can also give up before the server finishes. Calling all of these a session timeout loses the information needed to recover safely. Record which operation failed, its session identifier and the last confirmed page state before deciding whether another attempt is appropriate.

Read returned inactivity metadata

Lupin requests at most 600,000 milliseconds of Browser Run inactivity allowance. When a finite lease is shorter, the requested keep-alive is shortened as well. The response exposes idle_timeout_ms; it does not promise a fixed one-hour session. Activity and an established connection do not override the billing lease. In an enforced workspace, runtime reservation validates the plan and chosen duration before allocation. A shorter accepted duration can be the correct response to a billing-cycle boundary or budget restriction, but the task must then fit within that new bound.

Do not confuse access expiry with resource expiry

The connect response's access_expires_at is a five-minute startup deadline for the generated links. If the URL expires before the client connects, request fresh access for the same active session. That operation should not create another browser. If the session itself ended, new access cannot revive it; a new authorized session starts without the previous profile. Cloudflare's live-view documentation explicitly separates the startup deadline from the lifetime of an already established connection. Your user interface should therefore show access freshness and browser lifecycle as separate states rather than one ambiguous countdown.

Illustrative request; source reviewed, not executed against a live provider.
{"name":"short-research","timeout_seconds":60}

Treat page readiness as bounded work

The current action implementation waits for the requested navigation loader and document readiness instead of requiring universal network silence. Each protocol command and the whole action remain bounded. A navigation timeout may happen while the page continues changing, so read the current state before navigating again. A click that timed out could already have reached the application. Preserve the original idempotency key for its operation and do not invent a new key merely to bypass an uncertain result. A repeated side effect is usually harder to repair than a delayed observation.

Plan work that survives an expired session

Before allocation, estimate the number of page observations, expected human handoffs and cleanup steps the task needs. Keep a smaller optional scope that can be dropped when the budget is nearly exhausted. Save URLs, findings and completed-step records outside the session as the task proceeds; this is application bookkeeping, not durable browser checkpointing. Lupin does not persist cookies across closed sessions. If the deadline wins, report the partial evidence and unfinished step accurately, close or reconcile the resource, and let the next authorized attempt begin from an explicit state rather than an assumed recovered browser.

Sources & verification

Reviewed against the current Lupin route, provider adapter and shared input contracts, plus the linked official references. Examples were not run against live services.

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.

Put it into practice

Give your agent the right tools.

Review the API, workspace requirements and permissions before enabling a workflow.

Explore browsers