Workers just relaxed its six-connection limit!

Hey everyone, it's Shiichan! Today I've got a small-but-satisfying change for everyone building on Cloudflare Workers.

Cloudflare Changelog developers.cloudflare.com

What was announced?

Cloudflare's Changelog announced that the limit on simultaneous open connections for Workers has been relaxed. The cap of six open connections per Worker invocation is still there, but the way those connections are counted has changed.

The story so far

Until now, the simultaneous open connections limit held a slot for the entire lifetime of each connection. Even after the response headers came back, a connection kept occupying one of the six slots until its response body was fully read. So a 7th fetch() had to wait until an earlier connection finished completely, body read and all.

What changes

Now a connection frees its slot the moment its response headers arrive. That means the six-connection limit only constrains connections still in the initial "waiting for headers" phase. Once headers are received, you can keep as many connections open as you like.

In other words, Workers can now keep many connections open at once, as long as no more than six are stuck waiting for headers. That's a real win for Workers that fan out to lots of external APIs in parallel.

Dive Deep

The other nice part is that the Response closed due to connection limit exception goes away.

Previously, the runtime used a deadlock-avoidance algorithm that watched each open connection for I/O activity. If all six looked idle — even for a moment — it would cancel the least-recently-used connection to make room. In practice that heuristic was fragile.

For example, when a response used Content-Encoding: gzip, the runtime's internal decompression created brief gaps between read and write operations. The Worker was actively reading, but during those gaps the connection looked stalled. If several connections hit those gaps at the same time, the runtime could spuriously cancel one that was working fine.

By counting connections only during the waiting-for-headers phase — where the runtime is fully in control and there's no ambiguity about whether a connection is active — this whole class of bug is eliminated.

Wrap-up

• The six-connection limit for Workers now frees a slot as soon as response headers arrive
• As long as no more than six are waiting for headers, your effective number of concurrent open connections goes way up
• The spurious Response closed due to connection limit exception caused by gzip gaps is gone

If you write Workers that call many external APIs in parallel, or you've been chasing a mysterious connection exception, this one's for you.