DNS Failover: Keep Your Site Up When Your VPS Goes Down

Your VPS goes down at 2 a.m. — a kernel panic, a bad update, a host-side outage — and your site is just gone until someone wakes up and reboots it. DNS failover is the piece that catches that gap: it automatically points visitors to a backup server (or at least a "we're back soon" page) the moment your primary VPS stops responding. Here's how it actually works and how to set it up without paying for enterprise load-balancer pricing.

Symptom: One Server Down, Whole Site Down

You've got a single VPS hosting your site. The A record for your domain points at one IP. That's normal, and it's fine — until that one server has a problem. Then every visitor gets a timeout or a connection-refused error, and there's nothing DNS-side catching the failure. You find out from a customer email, not a monitor.

This is different from a slow site or a 502 from an overloaded backend. It's a full outage: the box is unreachable, and DNS is still confidently sending traffic to it because DNS has no idea anything is wrong.

Cause: DNS Doesn't Know Your Server Is Down

A plain A record is just a static pointer. It has no concept of "healthy" or "unhealthy" — it will keep answering with the same IP whether the server behind it is running or on fire. Getting failover means adding a health-check layer that can rewrite the answer DNS gives out, and doing it fast enough that visitors barely notice.

There are three practical ways to build this, in order of effort:

Fix: Set Up Failover

Option 1 — Cloudflare Load Balancing (easiest)

If your domain already uses Cloudflare, this is the fastest path:

1. In the Cloudflare dashboard, go to Traffic → Load Balancing and create a pool with your primary VPS IP as origin 1 and your backup server (or a static "site down" page host) as origin 2.
2. Set a health check — an HTTP GET to / or a dedicated /healthz endpoint, checked every 60 seconds, with a 2–3 consecutive-failure threshold before it marks the origin unhealthy. Don't set the threshold to 1; a single dropped packet shouldn't trigger a failover.
3. Create a Load Balancer object and point your domain's DNS record at it instead of the raw A record.
4. Test it: SSH into the primary VPS and stop Nginx (systemctl stop nginx). Within a couple of health-check cycles, Cloudflare should start serving from the backup origin. Bring Nginx back up and confirm it fails back.

This costs a small monthly fee per load balancer but needs zero scripting, and Cloudflare's health checks run from multiple global locations so a local network blip on their end doesn't cause a false failover.

Option 2 — DNS Provider Native Failover

If you're on Route 53, DNSMadeEasy, or a similar provider with built-in health checks, the pattern is the same idea without Cloudflare in front:

• Create a health check pointed at your primary server's IP and port (usually 80 or 443).
• Create a "primary" and "secondary" (failover routing policy) A record, associating the health check with the primary.
• Set TTL low — 60 seconds is reasonable. Lower TTLs mean faster failover but more DNS query volume; don't go below 30 unless you have a specific reason.

Option 3 — Self-Managed Failover Script

If you want zero recurring cost and are comfortable with a bit of scripting, a monitoring box (a small VPS separate from your main server, or even a free-tier instance) can watch your server and flip the DNS record via API when it goes down. The logic is straightforward:

1. Every minute, a scheduled job on the monitoring box requests a health-check endpoint on your primary server (something like /healthz) with a short timeout, say 5 seconds.
2. If that request fails or times out, the job calls your DNS provider's API to update the A record so it points at the backup IP instead of the primary.
3. Once the primary starts responding again, a second check flips the record back — don't leave traffic parked on the backup forever.

Two things matter here that people skip: run the check from a box that isn't the primary server itself (otherwise a network-level outage takes down your monitor too), and log every switch with a timestamp so you can see exactly when and how often failover fired. Most DNS providers (Cloudflare, Route 53, DigitalOcean, etc.) document a REST endpoint for updating a single record, so this is usually a short script rather than a full application — just be careful to store the API credential outside your web root and restrict it to DNS-edit scope only.

Prevention: Make Failover Actually Work When You Need It

• Keep TTL low on the record you're failing over. A 24-hour TTL means visitors (and their ISP's resolver cache) can keep hitting the dead IP for a full day after you've switched. 60–300 seconds is the usual range for a failover-capable record.
• Health-check the actual application, not just the port. A server can accept TCP connections on port 80 while PHP-FPM is jammed and every request times out. Check an HTTP endpoint that touches your app, not just "is something listening."
• Keep the backup target genuinely useful. A second full server is the real answer, but if that's not in the budget yet, even a static "we're back shortly" page on a different, cheap host beats a hard connection failure — it at least tells visitors something is happening.
• Test it on purpose, on a schedule. Failover you've never tested is failover you don't actually have. Stop the web server on the primary once a quarter and confirm the whole chain — detection, DNS switch, fail-back — works end to end.
• Watch your database, not just the web server. If your backup origin serves the same app but points at a database that's only on the primary, failover will "succeed" and still show broken pages. Plan for read-only or cached mode on the backup if full replication isn't realistic yet.

None of this needs to be complicated on day one. Even the simplest version — Cloudflare Load Balancing with a single backup origin — turns a full outage into a brief blip for most visitors, and that's usually the difference that matters.