What Happens When an Answering Service Goes Down?
You're in a deposition. A potential client (personal injury case, statute of limitations running out) calls your firm. Your answering service should pick up. Instead, they get silence. Or a busy signal. Or voicemail they'll never listen to.
That's the scenario every late-stage buyer of an answering service is playing out in their head. It's a fair concern. Every technology system goes down at some point. The question isn't whether your answering service will ever have a problem. It's what kind of problems are real, how often they happen, and what actually occurs when they do.
This guide is the honest answer to that question: what the failure points are, what failover actually means in practice, and how to evaluate reliability before you sign.
The Quick Answer
When an answering service goes down, callers typically reach a busy signal, silence, or fall back to your main business line or voicemail, depending on how your call forwarding is configured. The failure can happen at three distinct layers: the carrier forwarding path (the phone network routing calls to the vendor), the vendor's voice and AI platform (where calls are actually handled), or the notification layer (where summaries and alerts are delivered to you). A well-architected service with 99.97% uptime experiences under 3 hours of total unavailability per year, but that number is only meaningful if you know what it includes.
What Actually Fails in an Answering Service
Most outage conversations are vague: "the service went down." In practice, there are three distinct layers that can fail, and they fail for different reasons.
Layer 1: Carrier Forwarding
Before your answering service can answer anything, a call has to get there. Your business line forwards calls via your carrier (AT&T, Verizon, T-Mobile, etc.) to the answering service's number. If the forwarding configuration breaks (a carrier routing error, a mistyped transfer number, or a configuration that wasn't updated when you changed your forwarding rules), calls never arrive.
This is one of the most common sources of "the service went down" complaints, and it's usually a configuration issue. The call routing path from your business line to the answering service is maintained by your carrier, not your vendor.
Mitigation: Keep a written record of your current forwarding configuration. Test it when you set it up and after any changes to your business phone number, carrier account, or forwarding rules.
Layer 2: The Voice and AI Platform
This is the layer most people picture when they think "the service went down." It's where calls are answered: the voice infrastructure, the AI processing, the real-time conversation handling.
A platform outage can cause:
- Calls to fail immediately (caller hears nothing or a fast busy)
- Calls to answer but the AI doesn't respond (silent call)
- Degraded performance: the AI answers but responds slowly or makes more errors than usual
Modern AI answering services run on redundant infrastructure (distributed across multiple data centers), so full outages are rare. Degraded performance (where the service is technically up but slower or less accurate) is more common and harder to detect without monitoring.
Layer 3: Notification Delivery
You might not notice a platform issue until you check your missed-call summaries and realize nothing came through. Email delivery, push notifications, and webhook calls are a separate reliability domain from call answering. A call can be answered perfectly while the notification system is delayed or down.
This matters more than most vendors disclose. If you rely on email summaries to know a client called, and the email is delayed two hours, you've effectively missed the urgency signal even if the call was answered correctly.
What "Failover" Actually Means
Vendors use "failover" to mean different things. Before you put weight on it, get a specific answer.
Failover at the carrier layer means: if the primary number can't receive a call, calls route to a backup number. That backup might be your personal cell, a second answering service line, or a voicemail system. The call gets handled, just not ideally.
Failover at the platform layer means: if one data center or server cluster goes down, traffic shifts to another. This is standard for cloud-hosted services and is the most meaningful form of platform redundancy. It's what makes 99.97% uptime achievable: automatic recovery fast enough that most outages are invisible to callers.
No failover means: if the primary system fails, calls fail. This is more common than vendors admit, especially for smaller services that run on a single infrastructure provider without redundancy.
The honest version: failover doesn't mean your service never goes down. It means your service recovers quickly enough from most failures that the impact is measured in seconds, not minutes.
How to Read Uptime Numbers
99.97% sounds good. But what does it mean in real terms?
| Uptime SLA | Downtime per year | Downtime per month |
|---|---|---|
| 99.99% | ~52 minutes | ~4 minutes |
| 99.97% | ~2.6 hours | ~13 minutes |
| 99.9% | ~8.7 hours | ~44 minutes |
| 99.5% | ~43.8 hours | ~3.7 hours |
| 99% | ~87.6 hours | ~7.3 hours |
The difference between 99.97% and 99.9% is roughly 6 hours per year. That sounds small. But if those 6 hours happen during your firm's intake rush (9am to noon on a Monday when potential clients are calling), the actual business impact is much larger than the raw hours suggest.
Two questions worth asking every vendor before comparing uptime numbers:
-
What does this number include? Some vendors measure uptime on the API layer only, not end-to-end call completion. A call that connects but delivers a degraded experience might count as "up" in their SLA.
-
Where is the status history? Reputable services publish a status page with incident history. If a vendor can't point you to one, the number is marketing, not an operational commitment.
This is what a credible status page looks like: named incidents, the affected service, and a committed update interval. These are carrier and message-delivery incidents on Twilio's public status page, the layer underneath most answering services: the kind of failure that never appears in a platform's own "uptime" figure. Captured August 3, 2026.
A sample call: what a caller hears on NextPhone. The AI collects the project details, checks the address against the service area, and books the estimate without a human in the loop. On a live line it picks up in under 2 seconds.
The Questions to Ask Any Vendor Before You Sign
Most vendors won't volunteer this information. Ask directly.
1. What's your uptime SLA, and what does it include? You want: end-to-end call completion, not just API availability. Push for specifics.
2. What happens to calls during a platform outage? You want: a clear answer (calls route to X backup number, or you get a busy signal). Vague answers ("we work hard to minimize disruption") aren't answers.
3. Do you have a status page with incident history? A public status page with historical incidents tells you what actually happened, not what the vendor wants you to think happened.
4. How do you define "failover," and at what layer does it apply? Carrier layer, platform layer, both, or neither. You want specifics.
5. What's your typical maintenance window? Most services have scheduled maintenance. The question is whether they communicate it in advance and whether they schedule it during low-traffic hours (typically 2–5am in your time zone).
6. What's your notification reliability SLA? If email summaries are delayed, you're not getting the value you paid for, even if call answering is working. Ask separately.
7. Have you had any incidents in the last 12 months? What happened? A vendor who claims zero incidents in the last year either has no status page or isn't being honest. Ask for specifics and see how they respond.