The percentage is the smallest part of the promise
Every hosted chat vendor advertises an availability figure, and every one of them is chosen to look reassuring. The number is the part buyers read and the part that matters least. What decides whether the promise is worth anything is the material around it: what counts as downtime, what is excluded from the measurement, who gets to decide, and what you actually receive when the promise is broken.
None of that is hidden. It is simply in a different document from the one with the big number on it. The marketing page carries the percentage; the terms of service carry the definition. Read them in that order and you will misread both, because the definition is what gives the percentage its meaning.
This guide is about reading the promise you are being offered. If you are writing the promise you make to your own customers, that is a different document with different rules, and the two are easy to confuse.
Turn the percentage into minutes
Percentages near 100 all look alike. Minutes do not. Convert before you compare, because the gap between two figures that differ in the second decimal place is the gap between an afternoon and a coffee break.
- 99% is about 7 hours 18 minutes of allowed downtime in a 30-day month.
- 99.5% is about 3 hours 39 minutes.
- 99.9% is about 43 minutes.
- 99.95% is about 21 minutes.
- 99.99% is about 4 minutes 20 seconds.
Now ask the question that actually matters for a chat widget: does the allowance land inside your staffed hours? Forty-three minutes spread across a month at three in the morning costs a business with daytime-only coverage almost nothing. The same forty-three minutes at 10am on the day of a product launch is a different event entirely, and the percentage cannot tell them apart.
Also check the measurement window. A monthly commitment resets every month; an annual one lets a single bad week be absorbed by eleven good months. The annual version is a weaker promise wearing the same number.
The exclusions decide the number
The exclusion list is where an availability commitment is really written. Read it before the percentage and the percentage will make sense.
Scheduled maintenance is excluded almost universally, and reasonably so. The question is whether the agreement bounds it. A commitment that excludes scheduled maintenance without capping its duration, requiring notice, or confining it to a low-traffic window is not bounded at all.
Anything upstream of the vendor is normally excluded too: internet routing, your own connectivity, a DNS provider, a customer network. This is fair, and it is also the exclusion that covers the largest share of real-world failures.
Third-party dependencies deserve a specific question, especially if you are running an AI assistant. If the answer layer calls a model provider, then the model provider is now in your availability path, and it is usually not in the vendor availability commitment at all. Ask directly what happens to the widget when that dependency is slow rather than down, because degraded is the common case and it is rarely defined.
Partial failure is the exclusion nobody writes down. Most agreements define downtime as the service being unavailable. A chat widget that loads but never connects, or connects but delivers messages a minute late, is not unavailable by that definition, and it is the failure mode your visitors are most likely to meet.
What a service credit is actually worth
The remedy for a missed availability target is nearly always a service credit: a percentage of the monthly fee, refunded against future invoices. Do the arithmetic once, on your own plan, before you place any weight on it.
On a chat subscription costing tens of dollars a month, a credit worth a fraction of that fee is not a financial remedy. It is a signal of good faith, and it is worth treating as one rather than as insurance. The cost of an outage to you is the conversations you did not have, and no credit scheme is scaled to that.
Three details are worth checking, because they decide whether the credit is claimable at all:
- Do you have to ask? Most schemes are request-based, not automatic. If nobody on your side files, nothing arrives.
- Is there a deadline? Claim windows are often short and measured from the incident, not from when you noticed.
- Is there a cap? Credits are usually limited to some share of one month, so a catastrophic outage and a merely bad one can be worth the same.
The honest conclusion is that a credit is a reason to trust the vendor takes the target seriously, not a reason to skip having a fallback.
Who decides whether it was down
An availability promise needs an arbiter, and in almost every commercial agreement the arbiter is the vendor. They measure, they verify, and they confirm the duration. That is normal and not sinister, but it means your own evidence has to be good enough to start the conversation.
Ask what the vendor measures from. Availability measured at the data centre is a different figure from availability measured from where your customers are. A widget can be perfectly healthy on the vendor status board and unreachable from an entire region because of a routing problem or a certificate error on an edge node.
Ask how incidents are communicated, too. A public status page with subscription is worth more than a promise to email, because it turns a dispute about whether something happened into a shared record. Check whether the page is updated during incidents or after them, which you can verify by reading its history rather than by asking.
Measure it yourself, cheaply
Independent measurement changes the conversation from an argument into a comparison of records, and it costs almost nothing to set up. You do not need a monitoring platform.
Point an external uptime checker at a URL the vendor exposes for that purpose, from more than one region, at a one-minute interval. Well-designed APIs provide an unauthenticated liveness endpoint precisely so that pollers do not consume your API budget or require a credential to sit in a monitoring tool. Alert on two consecutive failures rather than one, so a single dropped packet does not page anybody.
Then measure the thing your customers actually experience, which is not the same. Once a day, from a real browser, load a page carrying the widget and confirm it appears and connects. A synthetic check like this catches the failures a liveness probe misses: an expired certificate, a content security policy that starts blocking the script, a mixed-content problem after your own site moves to a new domain. Those are usually faults on your side of the line, they are invisible to the vendor status page, and they look exactly like an outage to a visitor.
Keep the log. A year of your own measurements is the single most useful thing to have at a renewal conversation.
The promise you receive is not the promise you make
Teams frequently copy the vendor number into their own customer-facing commitments, which is how a support organisation ends up promising more than its supplier does. Your availability to your customers is the product of every layer: your website, your hosting, the chat platform, your staffing, and your own operating hours. It cannot exceed the weakest of them.
The practical version is to promise coverage rather than uptime. Customers do not experience a percentage; they experience whether somebody answered. A commitment to reply within a stated window during stated hours is one you can staff and verify, and it survives an infrastructure incident with an honest message attached.
Then decide in advance what happens when chat is unavailable. The fallback does not need to be sophisticated: a visible support email address, a contact form that does not depend on the widget, and a short note on the page. Deciding this while nothing is broken takes ten minutes; deciding it during an incident takes an hour you do not have. If the incident is on your side rather than the vendor side, the handling is different again.
How MyLiveChat fits
MyLiveChat states its availability commitment, including the exclusions and the service-credit remedy, in the Terms of Service rather than only on a marketing page, and it runs a public service status page you can read before you buy and subscribe to afterwards. Both are worth reading in the order described above: definition first, number second.
For independent monitoring, the public REST API exposes an unauthenticated liveness endpoint intended for exactly this use, so an external checker can poll it without a token and without consuming the rate budget your integrations depend on. The API reference documents it alongside the request headers every response carries.
The self-hosted option changes the calculation rather than removing it: the availability of the service becomes yours to run and to measure, which suits organisations that already operate infrastructure to a known standard and suits nobody who does not want that job.
What to measure
- Your own observed availability, from at least two regions, kept as a rolling record rather than a current status.
- Widget-loads-and-connects checks, separately from the platform liveness check. These fail for different reasons and the difference tells you whose problem it is.
- Downtime inside staffed hours, which is the only downtime that costs you conversations.
- Time to notification — how long between an incident starting and you learning about it from the vendor rather than from a customer.
- Fallback usage. If chat goes down and the alternative contact route sees no traffic, visitors did not find it, and the fallback exists only on paper.