Chatbot Uptime & SLA Calculator

What an uptime SLA actually promises

An uptime SLA is three things: a percentage of minutes in a period, a list of minutes that do not count, and a remedy. The percentage is the part everyone quotes. The exclusions decide what it means, and they are where the documents differ most. Intercom excludes up to three scheduled maintenance windows a year and anything caused by third parties. Twilio and Zendesk do not count an outage shorter than five continuous minutes. Botpress treats an OpenAI outage as excused downtime, which matters because a generative bot without its model is a bot that cannot answer. Landbot measures per 24-hour period rather than per month, so its 99% is a different promise from a monthly 99%.

The remedy is usually a service credit, a percentage of that month's fee. Sometimes it is not even that: Intercom's SLA pays no credit and instead lets you terminate the affected service after two consecutive missed months. None of these documents promises to pay for the conversations that did not happen, and none of them covers the other links in your chain. That is the gap this page is about.

The arithmetic of nines

Each additional nine divides the permitted downtime by ten. The table uses a 365.25-day year, a month of one twelfth of that (30.44 days) and a quarter of one fourth; a vendor that measures per calendar month gives you 44 minutes 38 seconds at 99.9% in January and 40 minutes 19 seconds in a 28-day February.

Two things about this table are easy to misread. The month figure is an average, and outages do not arrive in four-minute pieces: a 99.99% service that has a single 20-minute incident has spent four and a half months of budget in one afternoon and is still inside its annual promise. And the difference between 99.9% and 99.95% is half the downtime, 22 minutes a month, which is roughly the length of one incident.

Why your bot's uptime is lower than every vendor's SLA

Availability composes by multiplication. If service A is up 99.9% of the time and service B, independently, is up 99.9% of the time, the moments when both are up are 0.999 × 0.999, or 99.8%. Add a third at 99.9% and the chain is at 99.7%. The customer experiences the product of all of them, and the product is always below the weakest link.

A chatbot has more links than most operators list. A WhatsApp bot passes through Meta's Cloud API or a provider in front of it, then the WhatsApp Business API integration inside the bot platform, then the platform itself, then a language model if the bot is generative, then whatever webhooks you wrote to look up an order or book a slot, then the CRM or knowledge base those webhooks call. Five or six links is normal. A vendor's status page shows you one of them.

A worked example

The defaults describe a synthetic mid-market support bot, not a customer deployment. Three of the five links carry figures real vendors publish: a channel API at Twilio's 99.95%, a platform at the 99.8% Intercom and Botpress both put in their SLAs, and a model at the 99.9%OpenAI attaches to its Scale Tier. The operator's own webhooks and the CRM behind them are assumptions at 99.9% each, and the calculator says so in its warning. The target is 99.9%.

No link is below its own SLA, and the chain lands at 99.451%: about 4 h 01 min a month against the 43 min 50 s a 99.9% promise permits, which is 3 h 17 min over. Over a year that is 2 d 0 h 07 min of a bot that cannot answer, against a budget of 8 h 46 min. The figure the operator can honestly put in a contract today is 99.45%, two nines.

The share column is where the decision sits. Chatbot platform owns 36.4%of the chain's unavailability on its own, twice what any of the three 99.9% links contributes. Raise it to the 99.9% target and the chain moves to 99.551%. Make it perfect, which nothing is, and the chain reaches 99.65%: still short of the target, because the other four links between them are still spending 2 h 33 min a month. The promise in this example is not achievable by pressing on any one vendor. It is achievable by promising less, or by taking links out of the chain.

Fallbacks, and the one place they help

Redundancy composes the other way. Two independent alternatives fail together only when both are down, so their combined availability is 1 − (1 − a)(1 − b): two providers at 99.9% behave like one at 99.9999%. The calculator lets you attach a fallback to any link, and the example shows why the choice of link matters more than the fallback itself.

Put a second model provider behind the first, the fallback most bring-your-own-LLM platforms make easy, and the chain moves from 99.451% to 99.551%, recovering 43 min 35 s a month. Put the same redundancy on the platform instead, and the chain reaches 99.65%, 1 h 27 min back. The catch is that the second number is mostly theoretical: nobody runs two chatbot platforms in parallel with a live switchover. The link that would benefit most from a fallback is the one you cannot duplicate, and the link you can duplicate was not the problem.

Two conditions apply to every fallback the calculator counts. It must be independent, so a second model behind the same platform outage does nothing, and it must be automatic. A provider you switch to by editing a setting during the incident is a recovery plan, and the minutes before someone notices still count against the budget. Our BYO-LLM guide covers what the switch actually involves on the platforms that support it.

Credits are a discount, not insurance

The platform in the example is at 99.8%, which permits 1 h 28 min of downtime a month before the vendor owes anything. Spread evenly across 20,000 conversations a month, that is about 40 conversations the bot could not take, and at the default $3.24 a conversation (one human contact, eight minutes at $24.30 an hour, the figure our bot vs human cost calculator uses) it costs the operator about $129.60 a month with the SLA fully met. The month the vendor does miss, a 10% credit on a $500 fee is $50.00. The Intercom preset itself would pay nothing; 10% is the commonest first band in the table below.

That ratio is typical rather than unusual. Twilio, Zendesk, Dialogflow, Amazon Lex and Vercel all start their credit schedules at 10% of the fee; Manychat and Botpress start at 5%; Intercom pays none. Credits exist to make the SLA enforceable, and they do that. They were never designed to make you whole, and a procurement conversation that treats the credit schedule as risk transfer is pricing the wrong thing. The clause worth negotiating is the exclusion list, and the number to plan around is the one this calculator prints for the whole chain.

The error budget, month by month

A target is spent as the month goes on. At 99.9% the budget is 43 min 50 s; log a 25-minute incident on the 8th and 18 min 50 s remains, 57% of the month used, with the month closing at 99.943% if nothing else fails. Site reliability teams use exactly this arithmetic to decide whether a risky release ships this week, and it works just as well for a bot: a new integration or a model switch is a change that can fail, and the budget says how much failing you can still afford.

Where do the logged minutes come from? Your own monitoring, if you have it, and otherwise the vendors' status pages, most of which keep a history. Both undercount. A vendor's status page reports the vendor's incidents; the minutes when your webhook timed out because the CRM was slow are on nobody's status page but yours, and they are the reason the assumed links in the chain should become measured ones after a few months.

How to read a vendor's SLA before you enter it

Four questions, in the order they change the number. First, what plan does it apply to? Manychat's 99.7% is for the Premium plan, Botpress's 99.8% is Enterprise only, OpenAI's 99.9% is the prepaid Scale Tier and the pay-as-you-go API carries none, and Zendesk's 99.95% for Sunshine Conversations exists only when the order form includes the add-on. If your plan is not named, the figure is marketing, and it belongs in the calculator as an assumption.

Second, how is downtime measured? Dialogflow counts a five-minute interval as down when more than 5% of requests return a server error, and Manychat measures server-side error rate, ping tests and web tests. A slow bot that eventually answers counts as up on every one of these definitions, so an availability figure says nothing about the first response time your customers see; the response time SLA calculator is the tool for that promise. Third, what is excluded: scheduled maintenance, third parties, the model provider, incidents shorter than five minutes. Fourth, what is the remedy, and is there one at all.

What “no published SLA” means for the chain

The link every WhatsApp bot depends on has no SLA at all. Meta's support page for the WhatsApp Business Platform answers the question directly: it does not offer commercially available service level agreements for uptime or latency. Twilio's 99.95% is the API in front of Meta, not Meta. Anthropic documents its standard tier as best-effort, and the 99.5% on its legacy Priority Tier is a target the document names, with no remedy attached. Tidio and Voiceflow publish status pages and, in Voiceflow's case, a 99.95% marketing badge, but no SLA document with a percentage and a remedy.

None of this makes those services less reliable than the ones with a document. It does mean you carry the estimate. Enter your best figure, mark it as an assumption so the warning stays visible, and replace it with measured uptime from your own monitoring when you have it. A bot that answers from a knowledge base on a platform with no SLA, through a channel with no SLA, has a chain of assumptions, and the honest promise to a customer is the one that says so.

Published uptime SLAs we checked

Every figure below was read on the vendor's own SLA or terms page on 15 September 2026, with the date the document carries. The presets inside the calculator are drawn from this same list, so the two cannot disagree. Status pages, trust-center badges and “99.99% uptime” hero copy were not counted; only a document with a percentage and a remedy qualifies.

No published uptime SLA, as of the same date: Meta WhatsApp Cloud API (support page updated 19 November 2025); Anthropic Claude API (read 15 September 2026). Tidio and Voiceflow publish terms without an uptime commitment; Microsoft's Azure Bot Service SLA now lives inside a licensing document we could not read in full, so it is not listed rather than guessed.

Why we built it this way

Uptime calculators are a crowded category, and nearly all of them stop at the nines table. That table is one input to the decision. The question an operator has when a bot goes quiet is which of five vendors to call, and the question a buyer has before signing is what they can promise their own customers. Neither is answered by converting one percentage into minutes. The chain, the share column and the ceiling on a single fix are what we wanted, and the vendor data is on the page because typing the right number into the right row is where most of the work is.

Across the platform reviews on this site, performance and reliability is a scored criterion, and the recurring finding is that most platforms below the enterprise tier publish nothing. The table above is the first place we have put the ones that do side by side. Where a review says a vendor has no published SLA and this page lists one, the page is newer; the reviews are refreshed on their own cadence and will catch up.

What this calculator deliberately is not

It does not monitor anything. It never pings your bot, polls a status page or records an incident. If you want to know whether the bot is up right now, a monitoring service that sends a test message through the real channel on a schedule is the tool, and the minutes it records are what this calculator expects you to enter. A check that only fetches your website tells you the widget loaded, not that the conversation behind it works.

It does not read your contract. The scope notes in the table are our summary of a document on a date; the document governs, and vendors change SLAs without announcing it. Read the current version before a renewal, and treat what is written here as the reason to.

Limitations you should state alongside the number

The chain math assumes the links fail independently. They do not, entirely: a regional cloud incident can take the platform, your webhooks and the CRM down together, in which case the composed figure is pessimistic for that incident and the share column is meaningless during it. The same assumption makes a fallback look better than it is if both providers sit behind one point of failure.

Downtime is spread evenly across conversations. Real outages cluster, and one that lands in your busiest hour affects more conversations than the average says; one at 3 a.m. affects fewer. If you know your traffic shape, the conversations-affected figure is a floor for a daytime incident and a ceiling for an overnight one.

An SLA is a promise. What a vendor actually delivers is usually above it and occasionally well below. The calculator composes promises because promises are what you can find; measured uptime from your own monitoring is better data and should replace them row by row as you collect it. Nothing here is legal advice about what a specific contract owes you, and no single output should decide a commitment to a customer.

Related Chatbotscape tools and resources

Some review links below go to platforms we may earn a commission from. That relationship does not affect scores, rankings, or what this calculator computes. See our affiliate disclosure for how it works.

• Response time SLA calculator — the other SLA: how fast a person answers after the bot hands over, with Erlang C
• Bot vs human cost calculator — where the default cost of a lost conversation comes from
• LLM API cost calculator — pricing the second model provider a fallback needs
• Chatbot ROI calculator — the business case the downtime cost belongs in
• Bring-your-own-LLM guide — what switching model providers actually involves, platform by platform
• Chatbot regression testing guide — the changes that spend an error budget, and how to test them first
• Migrating vendors in 14 days — when the weakest link is the platform and you decide to change it
• The chatbot KPIs a board actually cares about — reporting availability upward without overpromising
• Webhook — the link in the chain you own, and the one no vendor status page covers
• Fallback intent — what the bot says when it is up but cannot answer, as opposed to when it is down
• Intercom review — the 99.8% SLA behind the example's platform row; its only remedy is termination, so the 10% credit in the example is the table's commonest band rather than Intercom's
• Manychat review — the 99.7% Premium-plan SLA in context, with Meta's side excluded
• Botpress review — Enterprise-only SLA with model-provider outages excused
• Landbot review — a 99% guarantee measured per day, and what that means in practice

FAQ

How do you calculate uptime percentage?

Uptime is the minutes a service was available divided by the minutes in the period, times 100. A month of 30.44 days has 43,830 minutes; if the bot could not answer for 90 of them, uptime was (43,830 minus 90) over 43,830, or 99.79%. Going the other way, a target of 99.9% permits 0.1% of 43,830 minutes, which is 43 min 50 s. The calculator does both conversions and uses a twelfth of a 365.25-day year as its month; vendors that measure per calendar month give you slightly more in a 31-day month than in February.

How much downtime is 99.9% uptime?

About 1 min 26 s a day, 10 min 5 s a week, 43 min 50 s a month, 2 h 11 min a quarter, and 8 h 46 min a year. Each additional nine divides those figures by ten: 99.99% allows 4 min 23 s a month, 99.999% allows 26 s.

Why is my chatbot's uptime lower than every vendor's SLA?

Because a conversation only completes when every service in the chain is up at the same moment, and the availability of a chain is the product of its links, not the lowest one. A channel API at 99.95%, a platform at 99.8%, a model at 99.9% and two systems of your own at 99.9% each multiply to about 99.45%, roughly four hours a month, while no vendor has breached anything. The calculator shows which link owns the largest share and what the ceiling is if you fix only that one.

Does WhatsApp have an uptime SLA?

Not from Meta. Meta's WhatsApp Business Platform support page states that it does not offer commercially available service level agreements for uptime or latency. A business solution provider in front of the Cloud API may publish one for its own API, as Twilio does at 99.95%, but that figure covers the provider's layer, not Meta's. In the chain, treat Meta as an assumption and use your own status history.

Does a fallback language model improve uptime?

Only for the link it backs up, and only if it is independent and automatic. Two independent providers at 99.9% each behave like a single link at 99.9999%, so the model stops being a source of downtime. If the model was not the weakest link, the chain barely moves: in the worked example a model fallback recovers about 43 min 35 s a month, while the platform, which cannot be duplicated, still owns the largest share. A fallback behind the same outage, or one that someone has to switch on by hand, counts for nothing.

What is an error budget?

The downtime your target permits in a period, spent as outages happen. At 99.9% the monthly budget is 43 min 50 s. Enter the minutes already logged this month and the calculator shows what remains, what share is used, and the uptime the month closes at if nothing else fails. Site reliability teams use the budget to decide whether a risky change ships this week or waits.

Is an SLA credit worth anything?

A credit refunds part of the fee. It does not pay for the conversations you lost. The commonest first credit band in our table is 10% of the month's fee; Botpress and Manychat start at 5%, and Intercom pays no credit at all, offering a termination right after two consecutive missed months instead. In the worked example the platform's own SLA permits about 40 lost conversations a month before anything is owed, which costs the operator about $130 at the default cost per conversation; the credit paid in the month the vendor does miss is $50.

Does the calculator send my data anywhere?

No. All math runs in your browser. Nothing you type is uploaded, stored, or logged, and refreshing the page clears it.

Can I embed this calculator on my site?

Yes, free. Copy the iframe snippet from the embed section on this page. The embed strips Chatbotscape navigation and keeps the calculator plus attribution.

Sources and basis

• Availability arithmetic. Series composition as the product of link availabilities and parallel composition as 1 − (1 − a)(1 − b), the standard independent-failure model of reliability engineering; downtime allowances as (1 − uptime) times the minutes in the period, on a 365.25-day year. The engine is held to these closed forms and to the worked example by a script that runs before every build. Reference derivation: High availability, percentage calculation, checked 15 September 2026.
• Vendor SLAs. Each row of the table above links the document it was read from and quotes the date the document carries, or the date we read it where it carries none. Scope and remedy columns are our summaries; the documents govern. All thirteen documents were read in full on 15 September 2026; the Intercom, Manychat and Anthropic pages were re-read before publication.
• Cost default. $3.24 a conversation is one human contact at the bot vs human cost calculator defaults: eight minutes of handle time at $24.30 an hour, which is an $18 wage at a 1.35 overhead multiplier. The $500 platform fee, 20,000 conversations a month and 10% credit are examples, not benchmarks.
• Worked example.A synthetic chain. Three links use figures from the SLA table; two are labeled assumptions. Nothing on this page reports measured uptime from a customer deployment, and no Chatbotscape review has measured a platform's availability over a month.