FDE Times: Integration hangs after ~1 hour — check pool TTL, not pool size
A 6 November FDE Times guide explains the classic post-lunch hang: firewalls/NAT/load balancers drop idle TCP without a close, pools keep handing out dead connections. Set maxLifetime below the shortest path idle timeout, retry in one layer with jitter, and alert on queue message age — not length.
FDE Times’s 6 November hands-on guide targets the failure that recurs “almost exactly every hour”: demos fine in the morning, first request after an idle stretch hangs and takes others with it. On your laptop nothing sits between app and database; at the client a firewall, NAT and load balancer each have idle rules that never made the integration docs.
Stateful network devices delete idle entries without sending TCP close, so the pool still thinks connections are healthy. The fix is a TTL shorter than the shortest idle timeout on the path (e.g. 50 minutes when the firewall cuts at 60) plus keepalive cleanup — not raising maximumPoolSize, which only creates more connections that can die and overload the client DB.
Stacked retries multiply (SDK × code × scheduler can turn one failure into 27 calls). Keep a single retry layer with full jitter, turn the others off, and for queues measure oldest-message age rather than length so a short backlog of late work is not mistaken for health.
Source: fdetimes.net