Some links on this page are affiliate links. They don’t change what we recommend - see our affiliate disclosure.

The community spent mid-October 2026 arguing about cloud resilience. The third data center incident at one major cloud provider and a stalled datacenter expansion at another dominated the discussion - the community reports this as a sign that “a single provider is a hidden risk.” Treat that as sentiment, not a fact: no provider publishes a guarantee that a whole region, let alone a datacenter park, will stay up. What you can verify is what your own single VPS does or doesn’t protect you from. This guide is that check: what an external health check catches, what DNS failover can really do, where to keep backups so they survive your host, and when a second provider is genuinely worth it.

The honest baseline: one VPS is one point of failure

Start from the constraint rather than the marketing. A provider SLA is a refund schedule, not an availability promise. DigitalOcean, for example, commits to a 99.99% monthly uptime percentage for each individual Droplet - and the unavailability that counts is loss of connectivity to the Droplet over its public, reserved or private IP, or loss of read/write access to its root disk, caused by DigitalOcean infrastructure failure.[1] That is narrow: your app returning 500s is not provider downtime, scheduled maintenance is excluded, and the SLA is per Droplet, not per account. A single Droplet hosting your app can fail for a thousand reasons none of which trigger a credit: your code, your disk filling up, a misconfigured firewall, a kernel panic, a process that died at 3am. A second VPS on the same provider removes the “one machine” failure but leaves the “one provider” and “one region” failure intact.

So the real question in the title is three questions, and they have different answers:

  1. Can you detect an outage fast, from outside the provider?
  2. Can you switch traffic to a healthy copy without manual heroics?
  3. Can you rebuild from scratch if the whole host is gone?

Most single-VPS setups fail at least two of these. Let’s fix each.

1. Health checks: the check has to come from outside

The most common mistake is treating your server’s own checks as the source of truth. If your box is up but its network path to the internet is broken, a check running on that box sees everything fine - systemctl is-active nginx returns active while nobody on the internet can reach it. The same blind spot hits uptime dashboards hosted on the same VPS: they report “all good” precisely because they share the failure.

A health check is only useful if the probe crosses a network boundary your app depends on. That means an external monitor, or health checking at an infrastructure layer in front of your app. DigitalOcean’s managed load balancers are the clearest example: the load balancer probes each backend with a configurable protocol, port and path; a check interval; a response timeout; and healthy/unhealthy thresholds, and it only forwards traffic to Droplets that pass - with an HTTP/HTTPS check, a successful response is in the 200–399 range, and the load balancer marks a backend unhealthy and stops routing to it after the configured number of consecutive failures (defaults in the cluster configuration: 3-second interval, 5-second timeout, 3 failures to mark unhealthy).[2][3] That is external, automated and fast. A global load balancer can spread the same thing across regions.[4]

For a plain single VPS without a load balancer, the minimum is a lightweight external monitor hitting your public endpoint (an HTTP probe from a host in another network, ideally another provider) that alerts you - and ideally triggers the DNS switch in section 2. Two practical signals that are free and provider-official:

  • Provider status pages. DigitalOcean’s status page tracks components per region (you can see each datacenter separately), Vultr exposes status as HTML plus JSON endpoints (status.json, alerts.json) for automation, and Hetzner keeps its own status page.[5][6][7] These tell you whether the provider sees a region-level problem - which is exactly the failure an on-box check misses.
  • Your own external probe. The status page says the provider thinks the region is fine; it does not say your instance answers. Probe your IP/endpoint from outside, on a short interval, and store the history someplace other than the box you’re monitoring.

Rule of thumb: if the outage you can’t detect is the one you most need to detect - the datacenter losing power while your uptime dashboard is in the same building - the check must live outside the provider.

2. DNS failover: what DNS can and can’t switch

DNS is the cheapest way to redirect traffic, and it is also the one with the most misconceptions. It cannot fail over instantly, and it never will, because of TTL caching.

Here is the mechanism in numbers. On Cloudflare (and this is representative of any serious DNS provider’s controls) a proxied record defaults to a TTL of 300 seconds - five minutes - and that value can’t be lowered; DNS-only records can go down to 60 seconds (non-Enterprise) or 30 (Enterprise), with Auto still meaning 300 seconds.[8] So the fastest realistic DNS flip affects resolvers within a minute or so for users who don’t have a cached answer, and users who do hold a cached A record keep talking to the dead IP until their cache expires. Five minutes of downtime for a 300-second TTL is optimistic - it’s the upper bound on how long the old answer lives. And that’s before you factor in that a resolver may keep serving a cached answer even after the authoritative TTL expires.

What DNS-failover can do reliably is active-passive routing with health checks, which is a solved, documented feature. AWS Route 53’s failover routing policy is the canonical example: you create a primary record backed by a health check and a secondary record, and Route 53 stops answering with the primary and starts answering with the secondary when the primary’s health check fails.[9] The health check is what makes it active-passive instead of just two records. Without a health check, DNS flips nothing - it just answers, dead or alive.

The practical implication for a self-hosted deploy:

  • Keep your record TTL low (the Cloudflare non-Enterprise floor of 60 seconds is a sane target) - before you need a failover, because TTL is fixed at the value users’ resolvers cached.
  • Pair the low TTL with a real health check so the switch fires automatically, not when you get a pager at 3am.
  • Expect recovery in tens of seconds to a few minutes, not milliseconds. If your app needs sub-second failover, DNS is the wrong tool - you need a proxy/load balancer in front or an anycast/CDN layer, which is a different architecture than “two VPSes and a DNS record.”

One more thing DNS does not do: it does not make two providers with different stacks interchangeable. Both standby copies have to be running the same deploy, reachable on the same probe path, or the health check that flips DNS will also flip users into a broken standby.

3. Cross-provider backups: your snapshot must outlive the host

Provider snapshots are the trap. A snapshot stored on the same provider as your app is fine for rolling back a bad deploy, but it is not a disaster-recovery backup: if the provider’s region dies - or the account goes away, or the DC that stored the snapshot is the one that failed - your recovery point went with it. Snapshot storage also has a habit of silently costing more than you expect. The real numbers as of this writing:

  • DigitalOcean snapshots: $0.06 per GB per month (same rate per GiB for volumes), with a flat $0.01 minimum; DO’s automatic backups are a percentage of the Droplet’s cost - 20% for weekly, 30% for daily on the flat-price plans.[10][11]
  • Vultr snapshots: $0.05 per GB per month.[12]
  • Hetzner snapshots: €0.0143 per GB per month - notably cheaper per GB; Hetzner’s automatic backups are daily copies with up to seven slots per server, bound to the server and deleted with it.[13][14]

The pattern to draw from those three is separate: pricing differs, but all of them tie your snapshot to the provider that took it. If you want the backup to survive a provider failure, the snapshot must live somewhere else. That means two things in practice:

  1. Rebuildable configuration, not just disks. Store the thing that makes the box reproducible somewhere provider-neutral and versioned: your deploy code in git, your IaC (Terraform, Ansible or a plain script that provisions the VPS), your environment/secrets in a managed secret store. “Config-as-code” is the only backup that survives a dead provider and works on a different provider.
  2. Off-provider data backup. For the state that changes (database, uploaded files), copy it out periodically to object storage or a host on a different provider - a nightly pg_dump shipped to S3-compatible storage on another cloud, for example. RPO should be defined by how much data you can afford to lose, not by whichever provider’s snapshot schedule you signed up for.

We’re testing the specific “provider A snapshot → restore on provider B” sequence on real accounts rather than quoting a number for it - the principle is simple, but cross-vendor restore is exactly the kind of step you don’t want to discover is broken mid-incident.

4. Two regions of one provider, or two providers?

This is the decision the whole post is building toward. Run two VPSes in different regions of one provider, or split across two providers?

Two regions, one provider is the cheaper, simpler option and covers the most common failure mode. The realistic failure across all three providers below is regional or datacenter-level, not “the whole company disappears.” DigitalOcean lists 16 datacenters across 13 regions, Vultr markets 34 cloud regions, and Hetzner runs six locations in four network zones (Falkenstein, Nuremberg and Helsinki in Europe, plus Ashburn, Hillsboro and Singapore).[15][16][17] A second region of the same provider survives a single-region incident - and provider status pages show exactly this granularity, with incidents frequently landing on one region while the rest stays green.[5] You lose the shared network/control-plane dependency, too.

Two providers removes the class of failure that a second region does not: a provider-wide fault, a strained upstream network affecting one vendor’s whole footprint, or a control-plane outage (for example, creation/API failures) that blocks you from spinning up a replacement inside the same vendor at the moment you need it most. The cost is real operational weight - two billing relationships, two dashboards/APIs, and two environments that must stay byte-compatible enough that one healthy copy can take all traffic without a half-migrated codebase breaking it.

There is a middle step worth naming: same provider, but the regions in different fault domains isn’t something every provider guarantees, so treat “two regions of one provider” as reducing-but-not-eliminating correlated risk, and relies on the provider’s independent operation. If the business dimension is “I cannot be down for a whole day for any reason,” the honest answer tends to be two providers. If it’s “I want to survive a bad deploy and an occasional regional blip cheaply,” two regions of one provider is usually the right spend.

The practical verdict

Walk your own setup through this checklist before buying a second box:

  • External check? Probe your public endpoint from outside the provider. If you can’t see an outage from outside, you don’t have monitoring.
  • DNS configured for failover? Low TTL (60s floor on Cloudflare non-Enterprise), a health check driving the switch, and a real standby - not a second A record that’s never tested.
  • Backups outside the provider? Snapshots are rollback, not disaster recovery. Rebuildable config in git plus off-provider data copies is what survives a dead host.
  • Standby tested? A standby you’ve never failed over to is a hobby, not a plan. Do a drill.

Then the rule: a second VPS on a second provider is justified when downtime is more expensive than the ops cost of running two environments. For a blog, a side project, or an internal tool, the answer is usually no - spend the money on solid backups and an external monitor instead, and keep the single box deliberately boring. For anything where customers lose money when you’re down, the cheapest reliable insurance is one standby region you’ve actually cut over to, and that’s where two providers stop looking like paranoia and start looking like the reasonable cost of the promise you’re making.

If you’re building the deploy itself, our guide to running a Next.js app on a VPS with Nginx and PM2 covers the single-node baseline you’d replicate, and the long-term versioning story in upgrading PostgreSQL to 19 shows how to keep rebuilds reproducible. For pricing and region differences across the usual first-choice providers, see our DigitalOcean vs Linode vs Vultr comparison.

Sources

  1. DigitalOcean - CPU Droplet SLA (99.99% per instance; unavailability = loss of connectivity over public/reserved/private IP or root-disk access, due to DO infra failure). https://www.digitalocean.com/sla/cpu-droplets - checked 2026-10-14
  2. DigitalOcean - Configure advanced load balancer settings in Kubernetes (health check protocol/port/path, interval 3–300s default 3, timeout 3–300 default 5, unhealthy threshold 2–10 default 3). https://docs.digitalocean.com/products/kubernetes/how-to/configure-load-balancers - checked 2026-10-14
  3. DigitalOcean - How to Manage Global Load Balancers (health checks; forwards only to Droplets that pass; HTTP/HTTPS success = 200–399). https://docs.digitalocean.com/products/networking/load-balancers/how-to/manage-global-load-balancers - checked 2026-10-14
  4. DigitalOcean - How to Manage Global Load Balancers (cross-region backend distribution). https://docs.digitalocean.com/products/networking/load-balancers/how-to/manage-global-load-balancers - checked 2026-10-14
  5. DigitalOcean Status - per-region component status and incident history (e.g. BLR1 networking disruption, 2026-10-03). https://status.digitalocean.com - checked 2026-10-14
  6. Vultr - Server Status (HTML status page plus status.json / alerts.json endpoints). https://status.vultr.com and https://docs.vultr.com/vultr-server-status-json-endpoints - checked 2026-10-14
  7. Hetzner - Status page. https://status.hetzner.com - checked 2026-10-14
  8. Cloudflare - Time to Live (TTL) documentation (proxied Auto = 300s; DNS-only 60s non-Enterprise / 30s Enterprise floor, up to 1 day). https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/ - checked 2026-10-14
  9. AWS Route 53 - Failover routing policy and health checks (active-passive failover driven by health checks). https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-failover.html and https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/welcome-health-checks.html - checked 2026-10-14
  10. DigitalOcean - Snapshots pricing ($0.06/GB/month, $0.06/GiB for volumes). https://docs.digitalocean.com/products/snapshots/details/pricing/ - checked 2026-10-14
  11. DigitalOcean - Backups pricing (Basic plans: weekly 20%, daily 30% of Droplet cost). https://docs.digitalocean.com/products/backups/details/pricing/ - checked 2026-10-14
  12. Vultr - Stored snapshots ($0.05/GB/month). https://docs.vultr.com/support/platform/billing/does-vultr-charge-for-stored-snapshots - checked 2026-10-14
  13. Hetzner - Cost-optimized cloud servers (Snapshots €0.0143 per GB per month). https://www.hetzner.com/cloud/cost-optimized/ - checked 2026-10-14
  14. Hetzner Docs - Backups & Snapshots FAQ (daily backups, up to 7 slots per server, deleted with the server). https://docs.hetzner.com/cloud/servers/backups-snapshots/overview - checked 2026-10-14
  15. DigitalOcean - Regional availability (16 datacenters across 13 regions). https://docs.digitalocean.com/platform/regional-availability/ - checked 2026-10-14
  16. Vultr - Datacenter regions (34 cloud regions). https://vultr.com/features/datacenter-regions/ - checked 2026-10-14
  17. Hetzner Docs - Locations (six locations, four network zones; Falkenstein, Nuremberg, Helsinki owned, Ashburn/Hillsboro/Singapore colocated). https://docs.hetzner.com/cloud/general/locations - checked 2026-10-14

Trend signal (not a fact source): the October 2026 community discussion of a third-datacenter incident at a major cloud provider (news.ycombinator.com/item?id=50040547) and a reported pause in one provider’s datacenter construction. Cited only as community-reported sentiment, per our sourcing policy.