workerd error: Too many open files, socket pool exhausted

TL;DR: Bound your concurrent outbound connections. Each isolate keeps a small pool of sockets per origin, so firing dozens of parallel fetches or DB connections starves it. Serialize or limit concurrency, reuse connections, and put database traffic behind Hyperdrive connection pooling.

workerd error: Too many open files, socket pool exhausted

1. Confirm the load correlation. Run wrangler tail under normal and heavy traffic.

Expected: the socket error appears only as concurrency climbs, not on single requests.

1. Find the unbounded parallelism. Search for Promise.all over large lists of fetches, per-request database clients that open a new connection, or fan-out loops with no concurrency cap.

Expected: you can point at the code that opens N connections at once.

1. Cap in-worker concurrency. Process the list in small batches instead of all at once, and await each batch before starting the next.

Expected: peak concurrent sockets stay in the single digits per origin.

1. Stop opening a database connection per request. Route database traffic through Hyperdrive, which pools connections on Cloudflare's side:

   const client = createClient(env.HYPERDRIVE.connectionString);

configured once per isolate and reused across requests. Expected: one pooled path to the database instead of a new socket per request.

1. Reuse fetch where possible. Keep-alive is automatic, but identical repeated fetches in one request should be deduplicated so one connection serves them.

Expected: fewer distinct sockets for the same work.

1. Load-test at realistic concurrency and watch tail.

Expected: no socket pool errors, and p99 latency stays flat instead of spiking.

Use this when

• fetches or DB calls fail with socket or file-descriptor errors under load
• each request opens its own database connection
• a worker fans out to many origins or many rows in parallel
• the error appears in production traffic but never in single-request local tests

Not for this skill when

• the error is the subrequest count cap (that is a different limit with its own fix)
• connections fail immediately even at low concurrency (that is auth, DNS, or firewall)
• the origin closes idle connections (that is a keep-alive or timeout issue)
• you are hitting a rate limit on the origin side rather than a socket limit on the worker side

Variant phrasings

• Cloudflare Worker too many open files
• workerd socket pool exhausted
• worker concurrent connection limit origin
• EMFILE Cloudflare Worker fetch
• database connections exhausted in worker

Why it happens

An isolate can only hold a small number of concurrent sockets per origin. Code that opens a fresh connection per request or per loop item multiplies sockets with traffic, and once the pool is full every new connection fails with the socket error. The pool is per isolate, so the failure is load-dependent and invisible in low-traffic tests. Pooling (Hyperdrive for databases, bounded concurrency for fetches) keeps the socket count flat while throughput scales.

Edge cases

• Hyperdrive pools per region, not globally. Extremely spiky multi-region traffic can still open many pooled connections. Size the database's max connections accordingly.
• Long-lived connections to slow origins hold pool slots. Set timeouts so a hung origin cannot pin the pool.
• WebSockets to the same origin also consume pool slots. Close idle sockets promptly.
• Retries multiply sockets. A retry storm under failure can exhaust the pool faster than the original bug. Bound retries and add backoff.
• Local dev does not enforce the same pool limits, so this class of bug only shows up deployed. Always load-test against the deployed worker.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_e4Qv9HAkV9feRYQ0MOBEpw