“What happens when the internet goes down?” is the standard objection to VoIP, and it embeds an assumption from the copper era: that a phone number is a wire, and if the wire is cut the number is dead. On a modern platform the number is a routing entry in the provider’s network. Callers reach the platform whether or not any particular office, device, or connection is up. The reliability question is therefore not “does the number work,” it is “where does the call go when the usual endpoint is unreachable,” and that has an answer at every layer.
This article gives the availability vocabulary (the “nines”), a way to read provider SLAs, the distinct layers where failure happens and what mitigates each one, and a continuity checklist for a small business.
Nines: availability as minutes per year
Availability is quoted as a percentage of time a service is up, and the percentages compress a lot of difference into small-looking decimals. Translating to downtime per year makes them comparable:
| Availability | Common name | Downtime per year | Downtime per month (approx.) |
|---|---|---|---|
| 99% | Two nines | About 3.65 days | About 7.3 hours |
| 99.9% | Three nines | About 8.8 hours | About 44 minutes |
| 99.99% | Four nines | About 53 minutes | About 4.4 minutes |
| 99.999% | Five nines | About 5.3 minutes | About 26 seconds |
Reading an SLA
A service level agreement is a refund policy, not an engineering guarantee. Three questions expose what one is worth. First, what is credited: most SLAs pay service credits proportional to downtime, capped at a fraction of the monthly bill, so the remedy for a day-long outage may be a few dollars. Second, what is excluded: scheduled maintenance, customer-side internet failure, force majeure, and upstream carrier incidents are commonly carved out, and the carve-outs often cover the likeliest failures. Third, what scope the percentage measures: a platform SLA covers the provider’s core, not the PSTN carriers it interconnects with and not the access circuit into your office. A five-nines platform behind a three-nines internet connection is a three-nines phone system.
Layers of failure and their mitigations
Outages are not one phenomenon. Each layer fails differently and is mitigated differently, and conflating them is how continuity planning goes wrong.
| Layer | What failing looks like | Mitigation |
|---|---|---|
| Office power or internet | Desk phones and Wi-Fi softphones at that site go unreachable. Calls still arrive at the platform. | Mobile apps on LTE/5G keep working independently of office infrastructure. Failover forwarding to a cell number is the floor every business should configure. A second internet connection or cellular backup router hardens the site itself. |
| A single device | One phone or computer dies or loses registration; everything else works. | Multiple registered endpoints per user (desk phone, desktop app, mobile app) so any one can answer. Simultaneous or sequential ring across them. |
| The platform | The provider’s own service degrades or goes down. Rare on mature platforms, and the failure the SLA actually covers. | Provider-side engineering: multi-region architecture, registration failover to healthy regions, redundant carrier interconnects so no single upstream takes voice down. Buyers cannot build this; they can ask about it and read the status-page history. |
| Carrier / PSTN | An upstream or terminating carrier has an incident; some calls to or from some networks fail regardless of platform health. | Largely out of everyone’s hands below the carrier level. Multi-carrier interconnects on the platform side reduce exposure. Major nationwide carrier outages happen every few years and take down mobile and landline traffic alike; no purchasing decision avoids them entirely. |
Graceful degradation is part of reliability
Continuity is not only about keeping calls ringing; it is about what happens when nobody can answer. A call that fails silently is an outage from the caller’s point of view even when every system is technically up. Unanswered-call handling is therefore part of the reliability design: Voicemail, transcription, and visual voicemail with transcription means a missed call becomes a readable message rather than a lost one, an AI answering layer can take messages and answer routine questions during an outage exactly as it does after hours, and auto-replies by text can acknowledge missed calls on numbers that support messaging. A business that plans the degraded path (who gets the voicemail email, who monitors it, what the forwarding target is) rides out most incidents without losing a customer.
The copper comparison
The folk memory that “landlines never go down” has a real basis: analog POTS lines were line-powered from the exchange, so a desk phone kept working during a local power cut. But the reliability lived in the exchange building, with its battery strings and generators, not in the copper itself. Cut lines, flooded cabinets, and exchange failures took POTS down too; subscribers just experienced it rarely enough to remember the technology as infallible.
That comparison is also becoming historical. Copper networks are being retired across the US and much of the world: carriers are decommissioning exchanges, regulators have permitted withdrawal of legacy services, and the replacement for a “landline” is fiber or fixed-wireless voice, which is VoIP with different packaging and which also depends on premises power. The practical successor to line power is the mobile network: a charged phone on LTE/5G is the battery-backed fallback of the current era, which is why forwarding to mobile is the floor of every continuity plan.
A practical continuity checklist
- Configure failover forwarding now, not during the outage: an unreachable-destination rule sending calls to a designated mobile number.
- Install the mobile app on at least two people’s phones and verify they can answer business calls over cellular data with the office network unplugged.
- Define the unanswered path: voicemail greeting current, voicemail-to-email pointing at a monitored inbox, an AI or answering layer if the business uses one.
- Check network basics at the office: router QoS, and a cellular-backup or secondary internet path if the site takes heavy call volume.
- Read the provider’s SLA and status-page history once, so expectations about platform incidents are set before one happens.
- Keep number portability paperwork in order (account numbers, PINs): in a prolonged provider failure, porting out is the ultimate failover, and it is faster when records are ready.
- Test the plan annually: unplug the office router for ten minutes and watch where calls actually go.