What Does 99.9% Uptime Actually Mean?

Three nines sounds like a promise. It is actually a budget, and it is smaller than the number implies, measured over a window you did not choose, on a slice of the system you do not care about.

Every connectivity provider, cloud platform and IoT vendor quotes uptime in nines. It has become the industry’s shorthand for “reliable”, and it is repeated so casually that most people buying it have never converted it into a unit they can feel.

So let us convert it, and then let us look at the four things the number quietly leaves out. By the end you should be able to read any uptime claim and know exactly what has been promised, what has been excluded, and what it will be worth to you when a site goes dark on a Friday afternoon.

First, the arithmetic

A year contains 8,760 hours, or 525,600 minutes. Availability is just the fraction of that time the service was working, so the nines convert directly into permitted downtime.

Three nines permits 8.8 hours of downtime a year. A full working day. If that is your smart meter fleet, nobody notices. If it is the comms link on a battery storage site during a grid event, or an EV charging network on a bank holiday, 8.8 hours is not “almost never down”. It is a bad afternoon that you have contractually agreed to accept in advance.

The jump between tiers is also worth internalising, because it is not linear in cost. Going from three nines to four does not mean working ten per cent harder. It usually means adding redundancy at every layer, which is where the money goes.

Gotcha one: uptime of what, exactly?

The single most important question about any uptime figure is what was being measured, and almost nobody asks it.

Uptime is nearly always defined as “the service responded successfully to a check”. That is not the same as “the customer’s goal was achieved”. The gap between those two is where most real outages live.

In cellular IoT specifically, all of the following are simultaneously true and routinely happen:

• The router is up, has an IP and reports a healthy connection, while the VPN certificate expired at midnight and nothing has reached your platform since.
• The SIM is up and attached, with a live data session on the operator’s records, while the APN’s DNS resolver or the IPX path back to the home network is broken.
• The network is up, all cells green on the operator’s dashboard, while your specific device is deprioritised as a roaming visitor and getting 0.3 Mbps at the time of day you need it.
• The platform is up, returning 200 on the health endpoint, while the ingest endpoint your devices actually use has been returning 500s for six hours.

Every one of those scenarios reports as available. Every one of them is an outage to the person who owns the asset. A provider measuring “did my core network respond” is telling the truth and telling you nothing.

The other half of this is the excluded list. Read the exclusions in almost any connectivity or platform SLA and you will find planned maintenance, upstream provider failures, radio coverage and congestion, customer equipment, and events beyond reasonable control. Between them those categories account for a large share of genuine downtime. What is left inside the measured scope is the part the provider is confident about, which is rather the point.

Gotcha two: nines multiply, and they multiply downwards

Here is where the marketing number really comes apart.

Availability in a series chain is the product of the availability of every link. Not the average. Not the worst. The product. Every dependency you add makes the total worse, even if the thing you added is individually excellent.

A cellular IoT deployment has roughly nine links between the sensor and the dashboard: the device application, site power, the router, the antenna and RF path, the SIM, the radio access network, the core and roaming path, your VPN, and your cloud platform. Give every one of them a respectable 99.9% and watch what happens.

That is the part worth sitting with. Nobody lied. Nine suppliers each quoted 99.9% and each delivered it. The customer, who cares only about the end to end path, gets 99.1% and nine times the downtime they thought they were buying, and there is no single party to complain to because every individual promise was kept.

Providers quote nines for their one slice. You inherit every slice’s error budget, and you add a few of your own. The chain does not average out. It compounds.

This also explains why “buy a better SIM” is such a persistent and unhelpful reflex when a fleet misbehaves. The SIM is one link. Improving one link in a nine link chain has a hard mathematical ceiling on how much it can help, no matter how much you spend. There is a longer treatment of exactly which nine links break and what each one is worth in SimWise’s piece on why no SIM guarantees 100% uptime, which works through the same maths from the connectivity supplier’s side and is unusually honest about the limits of what a SIM contract can promise.

Gotcha three: the measurement window does the heavy lifting

This one is rarely malicious and almost always material. The window over which uptime is averaged changes the answer enormously, and the provider picks the window.

Take a single four hour outage. One event, one afternoon, one truck roll.

Four hours out of a 730 hour month is 99.45%, which breaches a three nines monthly SLA and triggers a credit. The identical four hours out of 8,760 annual hours is 99.95%, which comfortably beats the same three nines target and triggers nothing.

So when a provider quotes 99.9%, ask over what period, and whether it resets. An annual window with no monthly floor means a provider can be completely dark for a full working day and still report a year in compliance. That is not a trick, it is just arithmetic, but you should know which arithmetic you agreed to.

Gotcha four: fleet availability is not device availability

This is the one that is specific to IoT, and in my experience it is the most expensive misunderstanding on the list.

When a connectivity provider reports uptime across your estate, they are usually reporting an aggregate. If you have 1,000 SIMs and 999 are connected, that reports as 99.9% availability and the dashboard is green.

But availability is not something a fleet experiences. It is something a device experiences. That one disconnected SIM is not at 99.9%. It is at zero. And it will be the site that matters, because it always is: the one with the angry customer, the compliance obligation, the revenue attached to it, or the engineer who has to drive to Inverness.

Worse, aggregate reporting actively hides the failure pattern you most need to see. One thousand devices each losing 8.8 hours randomly across a year is an entirely different problem from twenty devices being permanently unreliable while 980 are flawless. Both report as roughly the same fleet number. Only one of them is fixable, and it is fixable precisely because it is concentrated.

What the credit is actually worth

The last thing an SLA does is define the remedy, and this is where the gap between perceived and actual protection is widest.

Connectivity SLA remedies are almost always service credits, calculated as a percentage of the monthly fee for the affected connections. Consider what that means in practice. A 10% credit on a £2 monthly IoT SIM is 20 pence. If that SIM sits in an EV charger that lost you a day of revenue, or a BESS site that missed a dispatch window, or a landlord’s BMS that triggered a penalty in your own contract, the credit is not compensation. It is not a risk transfer. It is an apology denominated in pence, issued by a legal department.

None of this makes SLAs worthless. A real SLA gives you a defined escalation path, a named response time, a commitment to explain what happened, and a supplier who has skin, however thin, in the game. Those are genuinely worth having and you should insist on them. Just never build a business case on the assumption that the credit will cover your loss, because it will not be within two orders of magnitude of your loss.

So what should you actually ask for?

If nines are a budget rather than a promise, the useful questions change. Here is what I would put to any provider quoting you an uptime figure.

1. Uptime of which components? Get the scope in writing. Core network and platform, or radio access too? If radio is excluded, and it will be, they have excluded the layer that causes a large share of your outages.
2. Measured how, and from where? A single HTTP check from one location is not a measurement of your service. Ask what the probe is and what counts as a failure.
3. Averaged over what window? Monthly with a floor, or annual? An annual window absorbs a working day of darkness without registering.
4. Aggregate or per device? Insist on the distribution, not the mean. The mean is designed to be reassuring.
5. What is excluded? Read the list. Planned maintenance, force majeure, upstream carriers, your own kit. Then ask what percentage of last year’s incidents fell into those categories, and watch what happens.
6. What is the remedy, in pounds? Not as a percentage. In pounds, for one affected site, for one day. Compare that to what one affected site for one day costs you.
7. What is the time to diagnosis? This is the question almost nobody asks and it is worth more than the SLA. When a site goes dark, how long until somebody can tell you which of the nine layers failed? That number, not the uptime figure, is what determines your actual pain.

The honest conclusion

99.9% uptime means 8.8 hours of permitted annual darkness, on one slice of a nine slice chain, averaged over a window chosen by the person quoting it, reported as a fleet mean that hides your worst sites, and backed by a remedy worth about twenty pence.

That is not a scandal. It is just what the number is, and the providers quoting it are mostly not being dishonest. They are describing the part of the system they control, which is the only part they can describe. The error is on the buying side, where a figure about someone else’s core network gets read as a promise about your asset staying online.

The way out is not to hunt for a bigger number. Five nines on one link still leaves you at the mercy of the other eight. The way out is to accept that end to end availability is something you engineer rather than something you procure: know your nine layers, know which ones you own, instrument them so you can tell which one broke, and spend your money on recovering fast rather than on a contract that promises you will never need to.

Written by Peter Green. Downtime figures are direct conversions from the stated availability percentages. The nine layer chain example assumes each link fails independently, which is a simplification: in practice some layers are correlated, since router and application firmware are usually deployed together and can fail together. The direction of the argument holds regardless.