Voice AI reliability
The worst outage in voice AI isn't a red status page. It's the dead air a caller sits through right before the dial tone.
Voice AI reliability is not a percentage you check once a quarter. It is dozens of small, specific failure paths, engineered so a provider timeout, a missed transfer, or a failed webhook never becomes the caller's problem.
- A second voice provider, offered rather than forced
- Three tiers before the model goes quiet
- A dead-air watchdog with one job
- Retries, dead-letter, and replay on every delivery
One call's failure path
A voice engine timed out. The caller never knew.
This is not a benchmark or a status-page number. It is what one provider fault actually looks like from inside the system and from the caller's seat, side by side, in the order it happened.
session opened
greeting served from cache
Hears the agent greet them.
caller turn closed
intent: confirm tomorrow’s pickup time
Asks about tomorrow’s pickup.
agent turn opened
tts stream: primary provider
Hears the time confirmed.
caller turn closed
follow-up: asks about the return leg
Asks a follow-up question.
agent turn opened
tts stream: primary provider
Waits for the answer.
Faultfault: tts provider timeout
Nothing unusual.
Responsefallback engaged
secondary tts provider selected
Nothing unusual.
Responsebackground audio holds the line
ambient cue queued
A little office noise, same as any pause.
Responsedead-air watchdog: mutual silence detected
one-shot extend, then a nudge cue
Hears a soft “still with you.”
Resolvedfallback tts stream: first byte received
turn completes
Hears the rest of the answer.
caller turn closed
call wraps normally
Confirms and hangs up.
session closed
provider used written to session report
Already disconnected.
Inside the call
The voice pipeline has its own list of ways to fail
A model, a transcriber, and a voice engine are three separate vendors on every call. Each one gets a plan for the moment it stops answering, not a hope that it won't.
Three tiers before the model goes quiet
Every call has a primary model, an org-configured fallback model, and a platform last-resort model behind it. If the first one will not answer, the call moves to the next tier automatically rather than sitting on a single point of failure.
A second voice, offered rather than forced
Cross-provider fallback on speech and transcription exists, and it is opt-in by design. An earlier hard-coded version once moved a multi-tenant account onto a fallback vendor without asking and produced an eighty-second silence. The fix was not a better fallback; it was making the choice yours.
Something to listen to while the fix happens
The same background audio that already covers an ordinary tool-call wait, faint office ambience plus a short verbal filler, keeps running while a failing provider is swapped out. A caller hears the pause a real hold usually has, not a dropped line.
The backstop when the gap runs long anyway
A rule-based state machine watches for genuine mutual silence, not just a pause, and works through one extension, then a nudge, then, only if nothing else has worked, an emergency transfer. It never simply gives up and leaves a caller on an open, silent line.
When the human leg fails
A transfer is not one plan. It is what happens if plan one doesn't work
Handing a call to a person can fail two different ways: the carrier won't move it, or the person isn't there to take it. Both have a named next step rather than a dropped call.
At the network level
Ask the carrier first
A cold transfer starts by asking the carrier to move the call at the network level. When that request is honoured, it is the cleanest handoff available.
Bridge it yourself when the carrier refuses
Carriers decline that request more often than most platforms admit. When they do, the call is placed and bridged directly instead, with a thirty second ring timeout and noise cancellation on the new leg.
Mute, do not tear down
The agent’s own audio is disabled on the line, but the room itself is never closed. That is the only reason the recording and the session identity survive a transfer at all.
At the human level
A specialist declining is a handled outcome, not an error the platform has to recover from. The ring window is a setting, one hundred and twenty seconds by default, and which of the four paths above runs when it closes is chosen per agent ahead of time, not improvised mid-call.
cold_transfer
Hand the call over without the briefing rather than let it go nowhere.
voicemail
Route the caller to voicemail. Your specialist can also flag voicemail themselves when a machine picks up instead of a person.
retry
Ring the same window again rather than assume the first attempt was final.
hang_up
Close the call cleanly instead of leaving someone holding for a person who was never going to answer.
After the call ends
A missed webhook is a delivery problem, not a data-loss problem
Every call fires events to a customer's own system. Those deliveries fail sometimes, the same as any request over the open internet, so the platform treats a failed delivery as something to recover, not something to lose.
Signed, and the signature can rotate
Every delivery is HMAC-signed, and a secret can be rotated with an overlap window instead of a hard cutover, so rotating a key never means silently breaking every endpoint that trusted the old one.
A failed delivery is retried, not dropped
An endpoint that times out or errors gets retried on a schedule rather than a single fire-and-forget attempt.
Retries run out; the event still does not disappear
When every retry is exhausted, the event moves to a dead-letter state instead of vanishing. Delivery failing is treated as a fact worth keeping, not an error worth hiding.
A person can replay or resend it by hand
A dead-lettered event can be replayed once the endpoint is fixed, or resent on demand from the deliveries log. The webhooks tab on every call pod keeps that history attached to the call it came from, so it is never buried in a single global feed.
The caller never found out a provider blinked.
The honest limit
We don't put a percentage on a status page
Every mechanism above is real and checkable. What we won't do is compress a year of calls into one number and ask you to trust it.
What you will not find here
- A percentage on a status page
- A badge or a certification claim about how the platform will behave
- A promise about the future stated as a number
What you can check on any call, yourself
- provider_used
- Which vendor actually served the speech, transcription, and model legs of that specific call, including whether a fallback provider took over mid-call.
- caller_joined_at / agent_first_audio_at
- The exact moments the caller connected and the agent first made a sound, so a slow start is visible rather than asserted away.
- queue_hold_seconds
- How long, if at all, the caller waited before an agent was available.
- abandoned_pre_agent
- Whether the caller left before an agent ever joined the call, reported plainly rather than folded into an average.
These fields sit on every session report, next to the transcript, the tool trace, and the cost breakdown for that call. Check one call, or check a thousand. The mechanisms on this page are what produced the numbers you will find there.
Where this fits
Reliability is one layer, not the whole story
- The platform
The system these failure paths run inside
Reliability is one property of a larger architecture: five independently deployed services sharing one scoped database, built so a slow or failing layer never has to become every other layer’s problem.
See the architecture - The clock
The other side of the same pipeline
Latency and reliability share a stage: the dead-air watchdog and the background-audio mask both started as latency work before they became the backstop for a stalled provider.
See the latency engineering - The developer surface
The delivery mechanics, in full
Signing, rotation windows, retry schedules, dead-letter states, and replay: the webhook spec behind the delivery-integrity section above.
See the webhook spec
Questions
What operators ask about reliability
Still have questions?
Bring a call where something went wrong. We will show you the session report it produced.
Book a demo
Bring us a call that went sideways.
Point Zumu at a recording where a provider stalled, a transfer went unanswered, or a webhook never landed, and we'll walk through which mechanism on this page caught it, and what your own session report would have shown.
- No availability percentage, ever
- Ask for a session report on any call