Handling network changes and dropped outbound connections
Why a long-lived outbound connection eventually breaks, why your code must expect it, and how to make a service survive a reset without failing a request.
What this covers
Any connection your service holds open for a long time will eventually be broken by something outside your control: maintenance on the other side, a network path changing, or an idle timeout somewhere in between. This is normal, and the mistake is writing code that assumes a connection obtained at startup lasts forever. A database client should use a pool that can detect a dead connection and replace it. A message consumer should reconnect with a growing delay between attempts rather than retrying in a tight loop. And an outbound HTTP call should have a timeout, so a connection that has silently died fails quickly instead of holding a request open.
A page on Voroa’s specific network maintenance behaviour is not published today. The practices above apply to any hosting platform.