Playwright Headless Stall Report: Why Proxy Browser Workers Need Active Liveness Probes

A Playwright issue opened on September 12, 2026 described an intermittent container-CI condition in which context.newPage() and page.goto() stopped settling while browser.isConnected() continued to return true. The reporter observed the condition in a long-lived Bun process using Playwright 1.61.1 and Chromium headless shell build 1228. A process-local request to the same service still returned HTTP 200.

The issue was closed as not planned. It did not establish a confirmed Playwright defect, and the report did not include a minimal reproduction. It also did not implicate a proxy. The operational signal is narrower and still important: a transport-level connected flag is not proof that a browser worker can create a target, execute JavaScript or complete a navigation.

What the report did and did not show

The reporter described an intermittent rate of roughly 30 percent in one long-lived CI workload. They said they had checked common explanations including memory pressure, CPU and I/O throttling, PID exhaustion, shared-memory exhaustion, shared user-data directories, risky launch flags and an obvious browser crash. Those observations are useful triage notes, not universal exclusions.

Because the issue is closed without a confirmed root cause, teams should not copy its symptoms into a vendor verdict. Instead, treat it as a failure pattern worth detecting in their own controlled environment.

Source note: Microsoft Playwright issue “context.newPage() and page.goto never settle while browser.isConnected() stays true (headless_shell 1228, container CI),” opened September 12, 2026; closed as not planned.

Connected is only the first state

A production browser worker should expose separate health states:

• Process alive: the operating-system process exists and has not exited.
• Transport connected: the automation client still has a control channel.
• Runtime responsive: a bounded expression can execute in an existing page or context.
• Target creation responsive: a disposable page can be created and closed.
• Navigation responsive: a controlled page on an owned endpoint completes within its deadline.
• Proxy path healthy: DNS, tunnel, TLS and HTTP stages succeed through the intended route.

Collapsing these states into one Boolean creates false confidence. It can also amplify a small failure: the queue keeps assigning work to a worker that looks connected but cannot make progress.

Use a bounded probe ladder

Run the cheapest probe first and stop when a stage fails. Check the process identity and control connection, then execute a harmless expression with a short deadline. If the worker is idle, create and close a disposable page. Finally, navigate to a lightweight endpoint that you own and that returns a unique challenge value.

Each step needs its own monotonic deadline. An application-level timer should reject the operation even if the browser library never settles the underlying promise. Record the failed stage, elapsed time, browser build, library version, container identity and proxy route ID. Never log proxy passwords, session cookies or page contents containing customer data.

The probe endpoint should be outside the browser worker but inside your authorized test surface. A successful host-side fetch does not prove browser runtime health, while a successful browser probe through the proxy demonstrates more of the real application path.

Recover without creating a retry storm

When a liveness stage times out, stop assigning new jobs to that worker. Mark it suspect, allow already-confirmed idempotent work to finish only within a short grace period, and then recycle the browser process. If termination itself stalls, escalate to the container supervisor.

Limit replacement concurrency. A fleet-wide restart wave can overload proxy gateways, authentication services and origin endpoints. Use a circuit breaker per browser build and route pool, plus randomized backoff. Preserve the original timeout as the primary result; do not replace it with the outcome of an automatic retry.

Navigation is especially sensitive to ambiguous completion. A timed-out request may have reached the origin even when the client never received a final event. Use idempotency keys for state-changing workflows and verify state before replaying them.

Separate browser health from proxy health

Run a four-way comparison against an owned endpoint:

1. Host request without the proxy.
2. Host request through the proxy.
3. Browser navigation without the proxy.
4. Browser navigation through the proxy.

This matrix distinguishes a browser-runtime stall from DNS, proxy tunnel, TLS, origin or container-network failures. Capture resolution, connect, tunnel, TLS, first-byte and completion timing where your tooling permits. For HTTP negotiation questions, pair this process with the proxy ALPN negotiation audit.

If reconnect attempts begin multiplying, use the controls in the proxy retry-storm prevention guide. Teams investigating adjacent Playwright connection-reset symptoms can compare the Playwright keep-alive ECONNRESET report.

Release checklist

• Every asynchronous browser call has a caller-owned deadline.
• Health checks test runtime response, target creation and controlled navigation separately.
• Direct and proxied paths are measured independently.
• Suspect workers are drained before recycling.
• Replacement rate and retry concurrency are bounded.
• State-changing workflows use idempotency or state verification.
• Logs omit credentials, cookies and sensitive page data.
• Build, library, image and route identifiers are recorded for comparison.

FAQ

Does browser.isConnected returning true mean the browser is healthy?

No. It indicates that the client still considers the control connection present. It does not prove that the runtime can create a page, execute work or navigate successfully.

Does this report prove Playwright 1.61.1 is defective?

No. The issue was closed as not planned and did not provide a confirmed cause or minimal reproduction. Test your exact build and environment before drawing a conclusion.

Should a stalled worker be retried immediately through another proxy?

Not automatically. First determine whether the operation may have reached the destination, protect state-changing actions with idempotency, and cap replacement and retry rates.

Compliance note

Use browser automation and proxies only on systems you own or are authorized to test. Respect access controls, site terms, data-protection duties and rate limits. Liveness monitoring should improve reliability, not bypass restrictions.