What Happens to Your Traffic During a DNS Failover, Exactly?

Sixty seconds is the best case, not a guarantee. A resolver isn't obligated to honor your TTL exactly, some ISP and corporate resolvers cache more aggressively than the record specifies, and any client or application with its own DNS cache, a connection pool that resolved once and reused the connection, won't fail over until that cache expires or the connection drops. Plan for a real-world failover window meaningfully longer than your TTL, and test it under realistic conditions rather than trusting the TTL number alone.

Most DNS failover services run their own health checks from multiple external locations against an endpoint you specify, and mark a region unhealthy after a configurable number of consecutive failures. A single check location is fragile, since a network issue between the checker and your region can look identical to your region actually being down. Use checks from multiple independent locations and require agreement across a majority of them before failing over, or a normal transient blip between one checker and one region can trigger an unnecessary failover.

Failover routing is binary: primary is used exclusively until it's marked unhealthy, then traffic moves entirely to secondary. Weighted routing splits traffic by a fixed percentage regardless of health, useful for canary testing but not a failover mechanism on its own. Latency-based routing sends each client to whichever healthy region responds fastest for them, which is genuinely useful for multi-region active-active setups but adds complexity that a simple primary-secondary failover setup doesn't need. Most teams starting out should use plain failover routing and add complexity only once they have a specific reason to.

This is almost always a caching resolver or client-side DNS cache holding onto the old record past its TTL, or an application that resolved the hostname once at startup and never re-resolves it during the process lifetime. Test failover with a long-running client process specifically, not just a fresh DNS lookup from a terminal, since a fresh lookup will correctly show the new record while a live, already-connected client may not notice for a much longer window.

Run a scheduled game day where you intentionally fail the health check for the primary region, not just simulate it in a test environment, and measure real client-observed failover time end to end, including from a long-running connection. An untested failover plan that turns out to take far longer than the team believed is exactly the kind of gap worth finding on a scheduled game day rather than during a real outage. Weigh what you find against the actual downtime budget the business has signed up for: a commitment to three-nines availability leaves an annual allowance well under half a day, which a single slow failover can eat into meaningfully on its own¹.

Run the failover game day like this:

1. Schedule a game day and intentionally fail the primary region's health check, instead of only simulating the failure in a test environment.
2. Measure client-observed failover time end to end, including from a long-running client process that resolved the hostname once at startup.
3. Confirm health checks run from multiple independent locations, so one checker's network problem can't trigger a false failover.
4. Look for connection pools and application-level DNS caches that keep sending traffic to the old region after the record has updated.
5. Compare the measured failover window with your TTL, and plan around the longer real-world number.

Say your primary region goes down and the DNS record updates within seconds, well inside the TTL you configured. A backend service with a long-lived database connection pool, opened at process startup and never re-resolved, keeps sending traffic to the now-unreachable primary anyway, since the pool holds an already-established connection rather than performing a fresh lookup on every request. The service layer looks correctly failed-over from a DNS perspective while a specific internal client quietly keeps erroring until it happens to restart. This is why testing failover from a fresh terminal lookup alone gives a false sense of confidence.