Live Preview concurrent WebSocket session limit configuration

Answer first

StackBlitz public Live Preview documentation does not publish a hard maximum number of concurrent WebSocket connections per project, does not document an idle timeout duration for those connections, and does not expose a user-configurable setting to raise a Live Preview session limit.

That means there is no confirmed per-project cap to quote, no confirmed idle timeout to rely on, and no documented user knob to adjust. Any limit or timeout would be undocumented and therefore subject to change without notice.

Confirmed facts

• Live Preview creates a session per browser tab. Opening more tabs creates more WebSocket connections for the same project.
• No published maximum concurrent Live Preview WebSocket connections per project is available in current public docs.
• No published idle timeout value for Live Preview WebSocket connections is available in current public docs.
• No user-facing configuration option to set or request a higher concurrent session limit is documented.

Likely explanation vs uncertainty

Delayed updates or disconnections when many tabs are open are plausible symptoms of backend resource pressure, browser tab throttling, or intermediate network devices, but they are not proof of an enforced quota. WebSocket closures can originate from the browser, OS network stack, corporate proxies or load balancers, and StackBlitz service-side keepalives. Without documented limits, the connection-pool pressure hypothesis remains unconfirmed.

Practical steps for this case

1. Reduce concurrent previews. Prefer one active Live Preview tab per project and close or reload stale previews.
2. Measure empirically in your own project. Open a fixed number of Live Preview tabs and record connect/disconnect timestamps and update latency in browser DevTools Network tab.
3. Inspect WebSocket frames. Look for ping/pong heartbeats and close codes/reasons to distinguish service-side closure from browser or proxy closure.
4. Control variables. Repeat tests after closing background tabs, disabling extensions, and changing networks to rule out local throttling and middleboxes.
5. Check current sources. Review StackBlitz documentation, status communications, and support or account-plan information for any published Live Preview session limits or formal limit-increase request process. Limits may vary by plan or region.

Assumption: behavior is assessed as of 2026-10-16. Undocumented limits can change without notice.

To tailor the recommendation, what plan type are you using for the project? Plan tier can change whether a formal limit-increase request process exists.