SLA Uptime Calculation: Exclusions, Credits and How to Write One

An uptime SLA looks simple: "99.9% availability." The number hides a lot of choices about what counts as downtime, how it is measured, what is excluded and what you get when the promise is broken. If you buy hosting, those choices decide whether the SLA is worth anything. If you are an agency or freelancer promising uptime to clients, they decide whether you will end up paying for outages you did not cause. This guide walks through the calculation and the clauses that matter. For the percentage-to-minutes basics, see uptime percentages explained.

The basic formula

Most SLAs define availability for a measurement period, usually a calendar month:

availability % = (total minutes in period - downtime minutes) / total minutes in period x 100

Some providers use a more elaborate form based on the error rate of requests within five-minute or one-minute intervals rather than a simple up/down state. Read the definition in the contract rather than assuming.

What each level allows

These figures assume a 30-day month (43,200 minutes) and a 365-day year (525,600 minutes):

The month length matters: a 31-day month gives you slightly more allowed downtime at the same percentage. Providers that measure monthly reset the clock each month, so one bad hour in March does not carry into April.

Notice what 99.9% means in practice: about 43 minutes a month. A single outage of an hour breaks it, and so does a series of ten-minute blips.

How providers decide what counts as downtime

The headline number is only as meaningful as the definition of "down." Typical variations:

• Unavailable means no response, or errors above a threshold. Some SLAs count only a complete failure to respond. Others count a period as down when the error rate exceeds a stated percentage.
• Minimum duration. Outages shorter than a threshold (often one to five minutes) may not count at all.
• Scope. Does it cover the network, the virtual server or hardware, or your application? Most hosting SLAs cover the infrastructure they run, not your code, database queries or CMS plugins.
• Who measures. The provider's own monitoring typically decides. That is a conflict of interest, which is why you should run your own independent monitoring and keep its records.

Common exclusions

Almost every SLA lists situations that do not count against the provider. Read these carefully; they often account for most real-world downtime.

1. Scheduled maintenance, usually if announced in advance by a stated notice period.
2. Force majeure: events outside reasonable control such as natural disasters or widespread internet failures.
3. Customer-caused issues: misconfiguration, exceeding resource limits, vulnerable or buggy code, a compromised account.
4. Third-party services: domain registrars, DNS you host elsewhere, payment gateways, other APIs.
5. DDoS and abuse, sometimes excluded unless you pay for protection. See DDoS basics for website owners.
6. Suspension for terms violations or unpaid invoices.
7. Beta or free-tier services, which often carry no SLA at all.
8. Emergency maintenance, which providers sometimes treat differently from scheduled work.

Ask: what proportion of my likely outages would these exclusions swallow? A 99.99% SLA with broad exclusions can be weaker than a 99.9% SLA with narrow ones.

Service credits: what you actually get

When a provider misses its target, the typical remedy is a service credit, not a refund and not compensation for your lost sales. Common features:

• Credits are tiered by how far below target availability fell. For example, a small percentage of the monthly fee for a minor miss, and more for a severe one. The exact tiers vary by provider, so check the current terms.
• Credits are capped, commonly at the monthly fee for the affected service.
• You must claim them. Many providers require a support ticket within a deadline after the incident, with evidence. If you do not ask, you do not get it.
• Credits apply to future invoices rather than paying out cash.
• The SLA is usually stated to be your sole and exclusive remedy for downtime.

This is why an SLA is not insurance. If an hour of downtime costs you more than a month of hosting, the credit will not cover it. See the cost of ecommerce downtime for how to estimate your real exposure.

Collect your own evidence

To claim a credit or dispute a provider's figures, you need records that do not come from the provider:

• An external uptime monitor with timestamps for every failure and recovery.
• Evidence of what failed: status codes, error pages, DNS results. The outage root cause finder helps separate DNS, TLS, network and HTTP failures.
• A status page timeline, if you publish one, showing when you announced the incident.

Note that your monitor and the provider's monitor can disagree, for instance on sub-minute blips. A 5-minute check interval will not catch a 2-minute outage at all. Know your own monitor's resolution before using it as evidence. See how often should you monitor a website.

How agencies should write an SLA for clients

If you host or maintain sites for clients, resist the temptation to promise "99.99% uptime." Your uptime depends on your upstream host, DNS provider, CDN and the client's own plugins and content edits. Promise only what you can measure and control.

Principles

1. Never promise more than your upstream. If your host offers 99.9%, you cannot sensibly offer 99.99%.
2. Define the scope. Name the exact URLs or services covered (for example the homepage and checkout), not "the website."
3. Define how it is measured. Name the tool, the check interval, the locations, what counts as a failure (for example an HTTP status of 5xx or no response within a stated timeout), and how many consecutive failures confirm an outage.
4. State the measurement window. Calendar month is standard.
5. List exclusions explicitly: scheduled maintenance with notice, client-caused changes, third-party outages, force majeure, attacks beyond agreed protection.
6. Separate availability from response time. Uptime says the site responds; it says nothing about speed. Add a response-time target only if you will measure it.
7. Define the remedy. A small, capped credit against the next invoice is normal. State it as the sole remedy.
8. Define the claim process. Within how many days must the client report it?
9. Add a response commitment (acknowledge within a stated time during stated hours). You control this far better than uptime.
10. Commit to reporting. Send a monthly summary with uptime percentage, incidents and causes.

Sample clause wording

Availability. The Provider will use commercially reasonable efforts to keep
the Covered URLs (listed in Schedule A) available at least 99.9% of each
calendar month, measured by [monitoring tool] at 1-minute intervals from
multiple locations. A Covered URL is "unavailable" when [N] consecutive
checks return an HTTP status of 500 or higher, or no response within 30 seconds.

Exclusions. Unavailability caused by scheduled maintenance announced at least
48 hours in advance, Client-initiated changes, third-party services,
domain or DNS provider failures outside the Provider's control, or force
majeure is not counted.

Remedy. If monthly availability falls below the target, the Client may
request a credit of [X]% of that month's fee by notice within 14 days of the
end of the month. Credits are the Client's sole remedy for unavailability.

Replace the bracketed values with figures you have checked against your own infrastructure and your lawyer's advice. Notice the check interval: a clause that promises one-minute measurement needs a monitor that actually runs that fast.

Plan your downtime budget

A useful habit is to treat the SLA as a budget. At 99.9%, you have roughly 43 minutes a month. Spend it on planned maintenance (put it in maintenance windows if they are excluded), and keep a reserve for the unexpected. After each incident, run a short postmortem so the same cause does not eat the budget twice.

Next steps

• Set up independent checks with the uptime monitor.
• Publish incident history with a status page.
• Show your record with uptime badges.
• Learn the numbers in uptime percentages explained.
• Write up outages with the incident postmortem generator.

FAQ

Is 99.9% uptime good enough?

It allows about 43 minutes of downtime per 30-day month. That suits many small business sites, but not services where each minute is costly. Match the target to your cost of downtime.

Does scheduled maintenance count as downtime?

Under most SLAs, no, if it is announced with the required notice. Check the notice period and the maximum maintenance hours allowed.

Do I automatically receive service credits?

Usually not. Most providers require you to file a claim within a deadline and to supply evidence, so keep your own monitoring records.

Can I promise a client 100% uptime?

You should not. No provider guarantees it, and an SLA that promises it exposes you to credits you cannot avoid.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.