Voice AI SLOs and Error Budgets: The Enterprise Guide

Most enterprises can stand up a voice AI pilot in a fortnight. Keeping it reliable in production is a different job, and it is usually the one nobody scoped. McKinsey's 2025 State of AI survey found that around 88% of enterprises now use AI somewhere, yet only about a third have moved any of it into production. The teams crossing that line discover the same thing: a live voice agent is not a single system you can call up or down. It is a chain of external providers, any one of which can degrade without ever going offline.

That is why "is the agent up?" is the wrong question to build reliability around. A voice agent can answer every call and still fail every caller, because latency has drifted to three seconds or the model has started refusing valid requests. Reliability for a live agent is not a light that is green or red. It is a target you set deliberately, measure continuously, and spend down like a budget.

Site reliability engineering solved this for large services more than a decade ago, and the two ideas that did the work transfer cleanly to voice. The first is the service level objective, or SLO: the reliability target you commit to. The second is the error budget: the amount of failure that target permits before you stop shipping and start fixing. This guide applies both to the specific problem of a voice agent that depends on providers you do not control.

This guide is shipped by the team behind Dilr Voice, enterprise voice AI built for regulated deployments. The same reliability thinking runs through DATS, our five-stage AI consulting system.

What is an error budget for a voice AI agent?

An error budget for a voice AI agent is the amount of unreliability its service level objective permits in a set window, usually a quarter. If the SLO is 99.9% answer availability, the budget is the remaining 0.1%: roughly 43 minutes of allowed failure a month. Dilr Voice treats that budget as a finite resource the team spends on releases, provider swaps and experiments, rather than a number it hopes never to think about.

The concept comes straight from Google's site reliability engineering practice, and its power is that it turns an argument into arithmetic. In the canonical SRE text, Google puts it plainly:

"The error budget provides a clear, objective metric that determines how unreliable the service is allowed to be within a single quarter."

Read that carefully, because the word "allowed" is doing the heavy lifting. An error budget is not a target of zero failures. It is an explicit statement that some failure is acceptable, and a mechanism for deciding when you have had enough of it. For a voice agent, that framing is a relief. You will never hit 100%: the model layer alone guarantees it. What you can do is decide how much unreliability is tolerable, measure against it honestly, and change your behaviour when the budget runs low. That is the whole of the discipline, and it is what separates an AI operating model that survives contact with production from one that lurches from incident to incident. It is also the reliability layer that sits underneath every other operational decision, from post-go-live adoption metrics to the incident response runbook you reach for when the budget is already gone.

What availability SLO is realistic when you depend on providers you do not control?

No voice agent can be more available than the providers it chains together. Assume a single call path with no fallback and independent failures: multiply the availability of your telephony, speech and model legs, and the product is your ceiling. Dilr Voice sets each SLO against that composed ceiling, not against any one vendor's headline number, because a caller experiences the whole chain, not its strongest link.

Work an example with real, published figures. Twilio's APIs Service Level Agreement, effective 9 April 2026, commits to 99.95% monthly availability on its standard tier and 99.99% for the Enterprise Edition. Amazon Connect commits to a 99.99% Monthly Uptime Percentage, with service credits stepping from 5% of charges below 99.99% to 100% below 95%. Those are strong numbers for the telephony and contact-centre legs. Now chain them. If telephony holds 99.95% and you assume your speech-to-text and model legs each hold 99.9%, a common enterprise target, the naive product is 0.9995 x 0.999 x 0.999, or about 99.75%. That is roughly 108 minutes of expected unavailability a month, worse than any single leg on its own. Adding dependencies can only lower the ceiling.

The model layer is where those assumptions get generous. Published standard-tier uptime commitments thin out exactly where you lean hardest: the OpenAI API and Anthropic's standard API tier do not publish an equivalent standard-tier uptime SLA, and even where a hyperscaler wrapper such as Microsoft's Azure OpenAI Service does publish an availability SLA, it covers endpoint availability only, not latency or output quality. Speech vendors including Deepgram and ElevenLabs, and full-stack platforms such as Vapi, Retell AI, Bland AI, Synthflow and PolyAI, sit on the same underlying model providers, so their status pages inherit the same weather. The practical rule for any voice AI agent is that your SLO cannot credibly exceed the availability you can defend on your weakest committed dependency, and the model leg is usually it.

The same diagnostic logic underpins our AI placement diagnostic, a fixed-fee assessment that maps exactly this dependency chain before any deployment commitment, so the target you promise is one the architecture can actually hold.

How much downtime does each availability target actually allow?

Availability targets stay abstract until you convert them into minutes. Over a 30-day month, 99.9% allows 43.2 minutes of downtime, 99.95% allows 21.6, and 99.99% allows just 4.32. Each additional nine cuts the budget by roughly ten times. Dilr Voice picks a target the dependency stack can actually sustain, because promising a nine you cannot hold does not buy reliability, it only manufactures broken commitments and a stream of service-credit claims.

The reason those minutes matter is that downtime has a price, and enterprise buyers already know it. ITIC's 2024 Hourly Cost of Downtime survey, which polled more than 1,000 firms worldwide between November 2023 and mid-March 2024, found that a single hour of downtime now exceeds $300,000 for over 90% of mid-size and large enterprises, and that 41% of the enterprises surveyed put the hourly cost between $1 million and over $5 million. Those figures measure general IT downtime, not a voice agent specifically, so treat them as the broad commercial anchor rather than the price of your line going quiet. They explain why a customer will pay for a tighter SLO, and why you should never write one down that your failover architecture cannot defend.

Which SLIs should a voice AI SLO actually measure?

Availability is the least interesting number in a voice SLO. A caller does not care that the API returned a 200 if the agent took four seconds to answer or misheard the account number twice. Dilr Voice measures user-facing service level indicators, or SLIs: answer availability, end-to-end turn latency, speech recognition accuracy and task success, and it gives the ones that actually shape the call their own separate budgets rather than folding everything into uptime.

This is the pivot most teams miss. Uptime tells you the pipes are open; it says nothing about whether the conversation worked. A voice agent has at least four indicators worth a budget of their own. Answer availability is whether the call connects and the agent responds at all. Turn latency is how long the caller waits between finishing their sentence and hearing a reply, and above roughly a second it starts to feel broken. Recognition accuracy is whether the speech layer heard the words correctly, which you can only judge against a labelled sample, not a vendor benchmark. Task success, or containment, is whether the caller actually got what they rang for without a human. Each of these can fail while availability sits at a perfect 100%, which is exactly why a single uptime SLO gives a false sense of safety.

Setting these well is a measurement problem before it is a target-setting one. You cannot budget an indicator you do not log, so the observability and tracing work that lets you replay a single call end to end is a prerequisite, not a nice-to-have. Latency in particular needs care: measure it at the ninety-fifth or ninety-ninth percentile, not the mean, because a handful of four-second turns will ruin more calls than the average ever reveals. The DATS five-stage methodology treats SLI selection as a design decision made before launch, alongside the capacity plan, so the numbers you promise are the numbers you can see.

How do you spend a voice AI error budget deliberately?

You spend a voice AI error budget every time you take a risk with the live service. A model upgrade, a prompt change, a new integration, a failover to a standby speech provider: each one is a withdrawal. Dilr Voice tracks burn rate, meaning how fast the budget is being consumed, so a rapid burn early in the quarter triggers caution while a healthy balance frees the team to ship features and experiments without asking permission each time.

Failover is the case worth dwelling on, because it is where the availability arithmetic from earlier gets rewritten. That naive product-of-availabilities ceiling assumed a single path with no redundancy. Real reliability engineering breaks that assumption on purpose. Put a hot standby on your speech leg and its availability stops being a single vendor's number and becomes one minus the chance that both the primary and the standby are down at once, which is dramatically higher. That is precisely how you raise a leg above its naive ceiling. The catch, and the reason it belongs in a budget conversation, is that every actual failover event still spends margin: the swap adds latency, sometimes drops context, and always consumes engineering attention. A standby you never exercise is not a failover, it is a hope, so the drills that prove it works are themselves a planned, worthwhile withdrawal from the budget.

Burn-rate thinking also changes how you alert. Instead of paging on every blip, you page when the budget is burning fast enough to be exhausted before the window closes. A slow, steady burn that will comfortably last the quarter is not an emergency; a burn that will empty the budget in three days is, even if the raw error rate looks similar. This is the reliability equivalent of the synthetic load testing you run before go-live: you are managing a rate of consumption, not a single threshold, and the traffic ramp that follows a release is one of the largest deliberate withdrawals you will make.

What happens when the error budget is exhausted mid-quarter?

When the error budget is exhausted, the policy is simple and agreed in advance: stop shipping changes that add risk and redirect the team to reliability work until the budget recovers. Dilr Voice writes this into an error-budget policy before the quarter starts, so the decision to freeze a release is automatic and evidence-based, not a fight between the product roadmap and the on-call rota when tempers are already short.

Google's own practice is blunt about the consequence: when SLO violations expend the error budget, releases are temporarily halted while additional resources go into testing and system hardening, and they resume only once the budget is back in the black. The value of writing this down in advance is that it removes the argument. Nobody has to win a debate about whether reliability matters more than the next feature, because the team already agreed the rule when the numbers were calm. That is what makes an error-budget policy a governance tool as much as an engineering one, and why it belongs in the same conversation as DORA operational resilience for firms that answer to the FCA. A freeze is not a failure of the team; it is the system working as designed, and the contractual SLA you signed is exactly why the internal target that guards it has to bite first.

What is the best way to set a voice AI SLO in 2026?

The best way to set a voice AI SLO in 2026 is to start with two or three user-facing indicators, set targets your provider stack can actually sustain, and attach an error-budget policy that governs releases. There is no single correct number, and Dilr Voice tunes each target to the deployment, because a payments line and an internal IT helpdesk simply do not deserve the same nine or the same freeze rule.

Be honest about where this is overkill, because a criteria-based verdict has to concede its own limits. For a pre-launch pilot or a low-volume internal agent handling a few dozen calls a day, a full error-budget regime is bureaucracy you have not earned yet: a single availability SLI and a named on-call owner will serve you better than a policy document. The discipline earns its keep once the agent is on a revenue path or a regulated one, where a bad week has a price and a regulator or a customer will ask what your target was. It is also worth being clear that the managed platforms, Vapi, Retell AI, PolyAI and the rest, will show you their own status pages, but not your composed SLO across the whole chain. No vendor can set that target for you, because only you know what a failed call costs your business. If you want the target set against your actual architecture rather than a vendor's marketing, that is what our placement-first approach exists to do, and it is a conversation worth having with our team about Dilr.ai before you promise a number in a contract.

Is an SLO the same as an SLA?

An SLO is not an SLA. The service level objective is the internal reliability target your team commits to, and you usually set it tighter than anything you promise outside. The service level agreement is the external, contractual promise to a customer, backed by service credits when you miss it. Dilr Voice keeps the SLO stricter than the SLA on purpose, so the internal alarm fires with margin to spare before a contractual breach ever comes into view.

The full mechanics of writing the external commitment down live in our guide to voice AI SLA design, and the gap between the two is where most first contracts get burned.

How often should you review a voice AI error budget?

Review a voice AI error budget on the same cadence you set it, typically each quarter, plus an out-of-cycle review after any major incident. A quarter is long enough to smooth out one bad week and short enough to force a real decision. Dilr Voice reviews the budget monthly as an early-warning signal and resets it quarterly, so a steady burn is caught while there is still time to act, not at the moment it forces a freeze.

Want to see this applied to your stack? Try Dilr Voice in production, book an AI placement diagnostic, read the DATS methodology, or browse more in our strategy writing on running AI in production.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.