Uptime and SLA Guarantees Explained

What uptime and an SLA actually mean

Uptime is the share of time a service is available and working. A service level agreement (SLA) is the contractual document in which a provider defines how availability is measured, what level it commits to and what happens when it falls short. Hosting companies, cloud platforms, DNS providers and CDNs all publish SLAs, and the headline figure, such as 99.9% or 99.99%, often appears prominently on pricing pages.

The figure is useful, but it is only the start. Two providers advertising the same percentage can offer very different protection depending on how they measure availability, what they exclude and how you claim compensation. This guide explains how to read the numbers and the small print, and how to protect yourself regardless of what the SLA says.

Translating percentages into downtime

Percentages near 100 look similar, but the downtime they allow differs greatly. The table below converts common uptime levels into the maximum downtime permitted over an average month (about 30.4 days) and a year (365.25 days). Values are rounded.

You can calculate any value yourself: multiply the minutes in the period by one minus the uptime fraction. For a 30-day month at 99.9%, that is 43,200 × 0.001 = 43.2 minutes.

Notice that the measurement window matters. A monthly SLA resets every month, so a single long outage early in the year does not use up a yearly budget. Conversely, an SLA measured annually could, in theory, allow several hours of downtime in one go while still being met.

How providers measure availability

The definition of “available” is where SLAs differ most. Read the measurement section carefully and look for answers to these questions:

• What is being measured? The physical server, the network, the web server responding to HTTP, or your actual application? A host can meet a network SLA while your site returns errors.
• Who measures it? Most SLAs rely on the provider’s own monitoring, not yours. Some require you to supply evidence.
• How often are checks made? A check every five minutes can miss short outages entirely.
• What is the minimum outage length? Some agreements only count incidents lasting longer than a set number of minutes.
• Does partial degradation count? Very slow responses or errors on only some requests may not be treated as downtime.

Component SLAs and combined availability

Your site depends on several services in a chain: domain registration, DNS, hosting, the database, the CDN and any third-party APIs. If each component is independent and each must work, overall availability is roughly the product of the individual figures. Two components at 99.9% each give about 99.8% combined. Adding redundancy, such as a secondary DNS provider, can improve the result, while adding more single points of failure lowers it.

Common exclusions in the small print

Nearly every SLA excludes certain events from the downtime calculation. Typical exclusions include:

• Scheduled maintenance announced in advance, sometimes within a defined window.
• Problems caused by the customer’s own code, configuration or exceeded resource limits.
• Attacks such as distributed denial-of-service, depending on the provider.
• Failures of third-party networks or services outside the provider’s control.
• Force majeure events such as natural disasters.
• Suspension for non-payment or policy violations.

Exclusions are not necessarily unfair, but they change the real meaning of the headline number. A generous maintenance exclusion, for example, can allow regular planned downtime that never counts against the guarantee. On shared hosting, exceeding your account’s CPU or process limits usually counts as your issue rather than the host’s, which is one reason our guide to shared hosting configurations pays attention to resource limits.

Service credits and what you can claim

When a provider misses its target, the usual remedy is a service credit: a percentage of the monthly fee applied to a future bill. Credit tiers often scale with how far availability fell, and many SLAs cap total credits at a portion of, or at most the whole of, the monthly fee for the affected service. Terms vary, so always check your provider’s exact schedule.

A few practical consequences follow from this structure:

1. Credits are small compared with business losses. If your hosting costs a modest monthly fee, the maximum credit is limited to that amount even if an outage costs you far more in lost sales.
2. Credits are rarely automatic. Many providers require you to open a ticket within a fixed period after the incident, sometimes with logs or monitoring evidence.
3. Credits usually exclude consequential damages. Standard terms of service often limit liability to the fees paid.

This is not legal advice; contract terms differ by provider and jurisdiction. For high-value services, larger customers can sometimes negotiate custom terms, but most shared and VPS plans use standard, non-negotiable agreements.

Monitoring uptime yourself

Because providers measure their own performance, independent monitoring is the best way to know what your visitors actually experience. An external monitor requests your site from outside the hosting network at regular intervals and records the response code, response time and any errors.

A quick manual check from the command line shows the status code and total response time:

curl -o /dev/null -s -w "%{http_code} %{time_total}s\n" https://example.com/

For ongoing monitoring, a hosted service or a small script scheduled with cron is more reliable than manual checks. Useful practices include:

• Check from more than one location so a single network path problem does not trigger false alarms.
• Monitor a page that exercises your application and database, not just a static file.
• Check for expected content, since an error page can still return a 200 status.
• Keep alert history, which gives you evidence when filing an SLA claim.

Outages no hosting SLA covers

Some of the most common causes of downtime are administrative rather than technical: an expired domain, a lapsed SSL certificate or an unpaid hosting invoice. No hosting SLA compensates for these. TLDix helps here by tracking domain, SSL and hosting renewal dates and sending expiry alerts; you can add your assets in the domain panel and read more about avoiding lapses in our guide to preventing domain expirations.

Preparing for an outage before it happens

Good monitoring is most valuable when it is paired with a simple response plan. Write down who receives alerts, how to reach the host’s support quickly, where the provider’s status page is and what you will tell customers if the site is unavailable for an extended period. Keep login details for the registrar, DNS provider and hosting panel in a secure password manager that does not depend on the website itself. After each incident, note the start and end times, the cause the provider reported and whether you filed a credit claim. Over months, this record shows whether the provider consistently meets its promises and gives you solid facts if you decide to move to another host.

Choosing the right uptime level

Higher guarantees usually cost more, and they often require architectural changes rather than just a different plan. Match the target to the real cost of downtime:

These ranges are general guidance, not industry rules. The right target depends on your revenue per hour, customer expectations and the contracts you have with your own clients.

Questions to ask before you sign

Before committing to a provider, ask or look up the following:

• Is the SLA measured monthly or yearly, and what exactly counts as downtime?
• How much notice is given for scheduled maintenance, and is it excluded?
• How are credits calculated, capped and claimed, and within what deadline?
• Does the provider publish a public status page and incident history?
• What support response times apply during an outage?

A clear, specific SLA with a transparent status page is generally a better sign than a very high percentage hedged with broad exclusions. Combine a sensible guarantee with your own monitoring, off-site backups and renewal tracking, and you will be protected against far more failure modes than the SLA alone covers.