Uptime Monitoring and SLAs: What 99.9% Really Buys You

A 99.9% uptime SLA allows your site to be down for 43 minutes a month and nearly nine hours a year without your provider owing you anything. That is the honest translation, and it is the reason an SLA is a billing document rather than a reliability guarantee. What protects you is your own monitoring, a known recovery path, and a target you chose on purpose.

What an uptime SLA actually promises

An SLA is a conditional promise with a financial consequence attached. It says that if you meet certain conditions and the provider misses a defined threshold, you get a credit against your bill. It does not say your site will be up. Microsoft’s own guidance on reading service-level agreements puts it bluntly: SLAs are engineering signals rather than availability guarantees, and they do not promise that your users will avoid downtime.

That guidance makes two more points worth carrying around. First, the definitions matter more than the percentage: a 99.99% commitment is only as broad as what the document counts as downtime, and narrow definitions mean real problems can affect your users without breaching anything. Second, do not multiply SLAs together to estimate your system’s availability. It assumes independent failures, which is not how shared infrastructure behaves, and it flatters the result.

Read any SLA for the measurement method before you read the number. Time-based measurement asks whether the service was up during each interval. Request-based measurement divides successful responses by valid requests. Amazon’s CloudFront SLA is the second kind: it calculates an error rate for each five-minute period across the billing cycle and subtracts the average from 100%. A sharp outage that lasts twenty minutes barely moves a monthly average computed that way.

The arithmetic: what each nine buys you

The nines are easier to think about as minutes. A thirty-day month holds 43,200 minutes and a year holds 525,600, so each additional nine divides your allowance by ten. Here is the whole table, with the providers who publish each level.

Two things fall out of that chart. The jump from 99% to 99.9% is enormous in practical terms, from a working day a year to a long lunch, and it is usually free: it is the difference between a cheap plan and a competent one. The jump from 99.9% to 99.99% is much smaller in minutes and much larger in cost, because it means redundancy, failover and somebody on call. Most small businesses should buy the first jump and consciously decline the second.

A 100% SLA and a twenty-five minute outage

The most useful thing you can read about SLAs is a real incident report from a company that publishes one. On 18 November 2025 a configuration file in Cloudflare’s bot management system doubled in size and broke the software that reads it. The company’s own post-mortem records impact starting at 11:28 UTC, core traffic largely flowing again by 14:30, and all systems normal at 17:06. It describes the event as its worst outage since 2019.

Then, in a follow-up post setting out its resilience plan, Cloudflare records a second incident on 5 December 2025 in which its network failed to serve traffic for 28% of the applications behind it for about 25 minutes. Hold that 25-minute figure next to the table above. A 99.9% monthly commitment permits 43 minutes. An incident that took out a quarter of the internet’s shop windows for nearly half an hour sits comfortably inside the allowance.

None of that is a criticism of Cloudflare, whose post-mortem is more detailed and more candid than most. It is an argument about what you should expect from any provider at any price. Infrastructure fails, the good ones tell you why, and your business continuity plan has to assume a few hours a year of somebody else’s bad luck.

Service credits are a refund, not a remedy

When a provider misses its commitment, you get a service credit. It is worth reading how one is actually calculated, because the mechanics explain why nobody has ever been made whole by one.

Cloudflare’s Business SLA commits to serving customer content 100% of the time without qualification. The credit for a breach is the outage minutes multiplied by the share of your visitors affected, divided by the scheduled minutes in the month. So a one-hour outage affecting half your visitors in a 43,200-minute month produces a credit worth about 0.07% of that month’s fee. The same document caps total credits in any twelve-month period at one month of fees, and states that credits are your sole and exclusive remedy.

Amazon’s CloudFront SLA is more generous in structure and harder to trigger. Monthly uptime below 99.9% but at or above 99.0% earns a 10% credit; below 99.0% down to 95.0% earns 25%; below 95.0% earns 100%. You must open a support case with the words ‘SLA Credit Request’ in the subject, by the end of the second billing cycle after the incident, attaching your own request logs as evidence.

Which is why we tell clients to treat the SLA as a signal about how seriously a provider takes availability, and then ignore it operationally. The number tells you what the provider is willing to stand behind. Your own monitoring tells you what is happening.

Monitoring you control, for about nothing

External monitoring is the cheapest useful thing in this entire article. A service outside your infrastructure requests your pages on a schedule from several locations and tells you when they stop answering. That is it. The free tiers are genuinely sufficient for most small businesses: UptimeRobot’s free plan covers 50 monitors at a five-minute interval, with HTTP, port, ping, keyword and SSL expiry checks.

The interval is what you are paying for, and it matters more than it looks. A five-minute interval means an outage can run for up to five minutes before anybody knows, and short incidents can be missed entirely. For a brochure site that is fine. For a shop taking orders through the afternoon, a 60-second interval for $10 a month is an easy decision.

Set the alerting up properly while you are there. One channel that reaches a human out of hours, a delay of one or two failed checks before alerting so a single blip does not wake anybody, and a second recipient so the alert does not die in one person’s silenced phone. An unread alert is the same as no monitoring and costs the same as monitoring.

What to watch besides the home page

Monitoring the home page tells you the server is alive. It does not tell you the business works. The home page is often cached at the edge, which means it can keep answering cheerfully while your database is down and nobody can check out.

1. A page that touches the database. A category listing or a search result, not the cached home page.
2. A keyword check. Match a word that only appears when the page rendered properly, so a styled error page does not pass as a success.
3. The certificate expiry. The most embarrassing outage is a lapsed TLS certificate, and it is entirely preventable with a 30-day warning.
4. The domain expiry. Rarer, worse, and recoverable only with luck. Monitor it and keep the registrar contact address current.
5. One third party you depend on. Your payment gateway or booking system. When it fails you need to know it is not you.

Add response time to the same dashboard, because slow is the early warning for down. A page that normally answers in 400 milliseconds and has been taking two seconds all week is telling you something is wrong before it falls over. Our piece on why website speed matters covers which of those numbers reflect what visitors feel, and which are lab artefacts.

Setting your own target instead of borrowing one

Microsoft’s guidance draws a distinction worth stealing: an SLA is what your provider commits to, while a service-level objective is the reliability your own users actually need. It recommends using the SLA to inform your objective rather than adopting the provider’s percentage as your target, because your target has to account for your own code, your dependencies and how much downtime your customers will tolerate.

For a small business that exercise takes ten minutes and two questions. How long can the site be down during business hours before it costs real money? And how long can it be down before somebody phones? If the answers are ‘an hour’ and ‘twenty minutes’, your objective is clear and so is your monitoring interval. You do not need four nines. You need to find out within two minutes and have a route to a human who can act.

Then write down what happens when the objective is missed. Who gets called, what the status page or social media post says, who has the hosting login, and at what point you stop diagnosing and start restoring. That document is worth more than any SLA you will ever sign, and it costs an hour. If you are picking a provider at the same time, our guide to hosting types covers which tiers give you support that answers quickly enough to matter during an incident.

The five lines worth writing down now

If you do nothing else after reading this, do these five. Put an external monitor on a database-backed page with a keyword check. Add certificate and domain expiry monitoring. Route alerts to two people, one of whom will see them at night. Write a five-line incident note covering who to call and where the logins live. And read your hosting provider’s actual SLA once, so you know whether the number on the marketing page appears in the contract.

That takes an afternoon and costs between nothing and ten dollars a month. It will not prevent an outage, because nothing prevents outages. It will mean you find out before your customers do, which is the only part of this you actually control. And check the alerts on a phone as well as a laptop; our mobile-first design guide makes the same argument about everything else you test.

Eudora Technology sets up monitoring, alerting and incident runbooks remotely for clients across Europe, the Middle East, Asia, Africa and the Americas, and reads the SLA with you before you sign it. Our web development and hosting page explains how that works and what you keep afterwards.

If you do not currently find out about an outage until a customer tells you, we can set up monitoring, alerting and a one-page incident runbook this week. Get in touch with Eudora Technology to talk about your project.