Reliability

The AI wave moves fast. Your phone line shouldn't.

A missed call is a missed booking, a frustrated member, a lost customer. So we engineer the boring half of voice AI as seriously as the clever half. This page shows how, in detail.

The numbers below come from failover drills on live production traffic, not from a lab.

≈10 s
to move the floating address, measured in drills
< 2 min
from confirmed failure to answering calls again
2
datacenters behind one address
24/7
heartbeats, paging and an engineer on call

Architecture

Built to lose a datacenter

Every serious outage story starts with a single point of failure. We removed ours: the platform runs on two identical stacks in separate datacenters, with one floating address in front.

your number·one floating address
DC A · primary
voice agentsserving
SIP · mediaserving
≈10s
DC B · warm standby
identical stackidle
config syncdaily
watchdog · health check /15s · flips automatically

One floating address

Carriers and SIP trunks point at a single address that can move between datacenters in seconds. Your number, your trunk and your configuration never change during a failover.

A warm standby, not a cold spare

The second datacenter runs the full stack continuously: voice agents registered, telephony listening, certificates in place. It refreshes its configuration from the primary every day.

A watchdog that can't fail silently

An independent watchdog checks the primary every 15 seconds and moves traffic after repeated confirmed failures. The watchdog itself is guarded by a dead-man's switch: if it stops reporting, an engineer gets called.

Rehearsed on production

We don't trust designs, we trust drills. We have deliberately failed the primary during live traffic and watched real calls get answered by the standby, with two-way audio, before failing back.

Release discipline

Stability without staleness

Fast-moving platforms break things weekly. Frozen platforms fall behind the AI wave. We refuse both: new models land within days, but every change travels through the same gate before it may touch production.

Versioned releases on a fixed cadence, no casual pushes to production
Every release is exercised with real test calls on a staging number before rollout
After rollout, 48 hours of heightened monitoring before a release is called done
What a release must survive
release v1.1gated
staging deploypass
code-level testspass
real test callspass
validate as a userpass
rollout + 48h watchlive
failover-drill.log
$ failover-watchdog --tail
[check]  primary · https 200 · sip reachable   (every 15s)
[hb]     normal-state ping  uptime monitor    (every 60s)
[drill]  primary made unreachable, on purpose
[strike] primary DOWN 1/4 · world reachable 
[strike] primary DOWN 4/4 · outage confirmed
[flip]   floating address  standby · 9.4s
[verify] inbound call answered · two-way audio 
 drill passed · failed back · zero client changes

Monitoring

We know before you do

Every layer reports its health continuously: heartbeats every minute, synthetic checks from multiple regions, and paging that wakes an engineer. Below is what our failover drill actually looked like from the watchdog's perspective.

Heartbeat monitoring with escalation that calls a human
A dead-man's switch: silence itself triggers an alarm
Incidents are annotated and reviewed, not archived and forgotten

Talk to the team that runs it

If your phone line carries bookings, members or patients, stability is a requirement, not a feature request. We are happy to walk you through the architecture in detail.