Cloud Run max concurrency configuration for outbound connection pool safety

Recommended pool size calculation

Answer: set the outbound connection pool size per instance to

poolSize = Math.floor((socketLimit - overhead) / maxConcurrency)
With a typical socket limit of ~1000 and reserving 50‑100 sockets for inbound traffic, health checks and library internals, a max concurrency of 80 yields a safe pool size of about 11 connections.
Why this works (likely explanation)
Cloud Run does not limit how many outbound sockets each container instance may open; the limit is imposed by the underlying runtime environment. If each concurrent request opens its own pool connection, the total sockets used ≈ maxConcurrency × poolSize. Keeping the product below the socket limit prevents the hidden exhaustion that manifests as 502 errors or latency spikes.
Steps to apply
Determine your service’s max concurrency (set in Cloud Run configuration).
Choose an overhead reservation (50‑100 sockets) based on observed inbound traffic and library behavior.
Compute poolSize using the formula above.
Configure your connection‑pool library (e.g., HikariCP, node‑pg, http‑agent) with that max size.
Deploy the service and monitor Cloud Run metrics for 5xx errors, request start latency, and application‑level active‑connection counts exported via OpenTelemetry/Prometheus.
If errors appear, reduce poolSize and repeat; if headroom remains and latency stays low, you may cautiously increase.
Missing diagnostic detail
To refine the calculation, confirm the actual socket limit for your specific Cloud Run region and CPU allocation (e.g., via a test that counts open file descriptors). If the limit differs significantly from ~1000, recompute the pool size accordingly.