How Website Uptime SLAs Are Measured: 99.9% vs 99.99%

This page explains how website uptime is actually measured in a service level agreement, what the difference between 99.9% and 99.99% means in minutes, and which clauses decide whether an outage counts as an SLA breach at all. It is written for IT managers, digital leads and procurement teams comparing hosting and website support contracts.

What an uptime percentage actually buys you in minutes

An availability figure is a budget for failure. The percentage tells you how many minutes per period your provider is permitted to be unavailable before they are in breach. Most buyers read 99.9% as "basically never down" and 99.99% as "a bit better than that". The gap is larger than it sounds.

Read the 99.99% row carefully. Four minutes a month is shorter than most reboots, shorter than a DNS propagation delay, and far shorter than the time it takes a human being to read an alert, open a laptop and log in. A genuine 99.99% commitment cannot be met by a person responding to a pager. It has to be met by automation: health checks that pull a failing node out of a load balancer, a standby database that promotes itself, a CDN that serves stale content when the origin stops answering.

That is why the number is not really a promise about reliability. It is a description of an architecture. If a provider offers 99.99% on a single virtual machine with one database on it, the number is marketing, because a kernel update or a disk failure will blow the annual budget in one event.

Monthly, quarterly and annual measurement windows change everything

The same percentage means wildly different things depending on the period it is calculated over. A 99.9% monthly SLA caps a bad month at 43 minutes. A 99.9% annual SLA permits a single 8 hour 45 minute outage with no breach at all, as long as the rest of the year is clean.

Annual windows favour the provider in a second way too. Service credits are usually calculated against the period in which the breach occurred, so an annual measurement means you cannot claim anything until the twelve months close, by which time the commercial damage is a memory and the contract may already have renewed.

Ask three questions of any availability clause:

• What is the measurement period? Monthly is the only window that reflects how an outage actually feels to a business.
• Does the clock reset on renewal or on calendar months? Mid-month start dates create partial periods that some agreements simply exclude.
• Is availability calculated per service or across a bundle? If the CMS, the API and the payment integration are averaged together, a total checkout failure can disappear into a compliant overall number.

Who measures it, from where, and how often

An SLA is only as honest as its measurement method. A surprising number of agreements never say who holds the stopwatch.

Check interval

If the monitor polls every five minutes, the smallest detectable outage is five minutes, and anything shorter is invisible. On a 99.99% target with a four minute monthly budget, a five minute check interval makes the SLA unmeasurable by definition. Enterprise monitoring should be polling at 30 or 60 second intervals, with confirmation from a second location before an incident is declared.

Check location

A monitor running inside the same data centre as the server will report the site as healthy during a transit or routing failure that makes it unreachable from Australian ISPs. Checks should originate from multiple external regions, including at least one Australian point of presence, so that the result reflects what a customer in Parramatta or Toowoomba experiences.

What counts as "up"

A TCP connection on port 443 proves almost nothing. PHP can be fatally erroring, the database can be refusing connections, and the server will still complete a handshake. A meaningful check asserts an HTTP 200 status, a maximum response time, and the presence of a known string in the rendered markup. Better still, a transactional check logs in, adds an item to a cart or submits a form on a schedule. The distinction between simple ping checks, synthetic transactions and real user data is covered in detail in our guide to synthetic monitoring, RUM and alerting.

Whose data wins

If the provider's own dashboard is the sole source of truth, you have no ability to contest a disputed month. Good agreements name the monitoring platform, grant the client read access to it, and allow an independent third-party monitor to be used as corroborating evidence.

The exclusions that remove most real outages from the calculation

The availability percentage sits at the front of the document. The exclusions sit near the back, and they are where the number is quietly refunded. Commonly excluded:

• Scheduled and emergency maintenance
• Failures of third-party services: payment gateways, CRM and marketing platforms, DNS registrars, external APIs, font and script CDNs
• DNS misconfiguration or expiry where the client holds the registrar account
• Expired TLS certificates on domains the provider does not manage
• Denial of service and traffic spikes above a stated request or bandwidth ceiling
• Anything caused by client-deployed code, a plugin or module installed by the client's own team, or a content change
• Force majeure, upstream carrier faults and cloud provider region failures
• Issues the client did not report through the designated channel within a stated window

Taken together, these can exclude the majority of outages a typical enterprise website suffers in a year. A plugin conflict after an update, a certificate nobody renewed, a Cloudflare rule change: all real downtime, none of it countable. That last bullet deserves particular attention. Some agreements require the client to report the outage before the clock starts, which means an overnight failure detected at 8am counts as minutes, not hours, regardless of when it began.

Planned maintenance windows and how they are counted

Nearly every SLA excludes planned maintenance, and that is reasonable. Operating systems need patching, databases need version upgrades, and security patches cannot wait for a quiet quarter. What matters is the shape of the exclusion:

• Notice period. Five business days is a common and workable standard. "Reasonable notice" is not a standard.
• Window placement. A maintenance window in AEST overnight hours is very different from one scheduled against a United States business calendar.
• Total monthly cap. Without a cap, unlimited excluded maintenance makes the availability figure meaningless.
• Emergency maintenance. Zero-day patching needs to be allowed, but it should be reported afterwards with a reason, not used as a blanket excuse.
• Who approves it. Retail and government sites usually need a change freeze around peak trading, end of financial year or a campaign launch.

The better answer is to reduce the need for the window at all. Rolling deploys behind a load balancer, blue/green releases and database migrations written to run online mean most routine work happens with no user-visible interruption.

Partial outages: slow, broken checkout, failed forms

Most commercially damaging incidents are not total outages. The homepage returns 200 while the enquiry form silently fails to send. The site loads in eighteen seconds under load. Search throws a 500. Checkout accepts a card and never writes the order. In a binary up/down SLA, every one of those months reads 100%.

A contract that reflects reality defines degraded service as a measurable condition and attaches a severity to it. Workable definitions include a response time threshold on named URLs, an HTTP 5xx error rate above a percentage of requests over a rolling window, or the failure of a specific synthetic transaction such as a test checkout or form submission. Pair those with a severity matrix and response targets and the agreement finally covers the failures that cost money.

Service credits and why they rarely cover the loss

The remedy for an SLA breach is almost always a service credit: a percentage of that month's fee, applied to a future invoice. Typical structures refund 10% for a modest miss and scale to 25% or 50% for a severe one, with an overall cap at 100% of one month.

Set that against the exposure. For an ecommerce site turning over meaningful revenue daily, or a government service where the outage becomes a ministerial question, a partial refund of a hosting fee is not compensation. Credits also tend to carry conditions: the client must claim in writing within a set number of days, provide supporting evidence, and be current on all invoices. Unclaimed credits expire.

Treat credits as a signal rather than a remedy. A provider willing to put real money at risk is telling you they expect to meet the number. A provider whose maximum exposure is one month of fees, behind a wall of exclusions, is telling you something else. If you are already in this position, our guide on what to do after an SLA breach covers evidence gathering and escalation.

What each availability tier actually requires

Each step up roughly doubles the infrastructure footprint and adds a layer of operational complexity: session handling has to move out of the application server, file uploads have to move to object storage, deployments have to be orchestrated across nodes, and the database schema has to tolerate two application versions running at once. None of that is free, and none of it is worth buying unless the business impact of an hour offline justifies it. The honest conversation starts with the cost of downtime, not with a percentage.

Response and resolution targets matter more than the availability number

Here is the part most buyers discover too late. The availability percentage governs infrastructure the provider controls. It says nothing about what happens when the problem is in the application, which is where the majority of serious incidents originate.

A pure hosting SLA commits to the server responding. If a CMS upgrade breaks a template, a module throws a fatal error, or a form integration stops posting to the CRM, the host will confirm the server is healthy and close the ticket. The site is still broken. This is the gap between shared hosting and genuinely managed hosting, and it is where most vendor finger-pointing happens.

The commitments worth negotiating hardest are therefore:

• Time to acknowledge. A named human responds, by severity, including outside business hours. Fifteen minutes for a P1 at 2am is meaningful; "next business day" is not.
• Time to begin remediation. Distinct from acknowledgement. An automated reply is not work starting.
• Time to restore service. A target for returning the site to a usable state, which may mean a rollback rather than a fix.
• Who may raise a P1. Named contacts, a phone path that reaches an engineer, and no requirement to file a web form during an outage.
• Scope of remediation. Explicitly whether application-layer faults, CMS and plugin defects, and third-party integration failures are in scope, or whether they become billable project work.
• Root cause analysis. A written post-incident report within a set number of business days, with the corrective action named and tracked.

A contract with 99.9% availability, a 15 minute P1 acknowledgement, a 4 hour restoration target and application-layer faults in scope is worth considerably more than a 99.99% badge attached to infrastructure only. Pair it with a credible emergency support arrangement so there is a known path for the incidents nobody predicted.

Frequently Asked Questions

How much downtime does a 99.9% uptime SLA allow?

A 99.9% uptime target allows 43 minutes of downtime per calendar month, 2 hours 11 minutes per quarter, or 8 hours 45 minutes per year. Which of those applies depends entirely on the measurement window named in the agreement. An annual window permits a single outage of almost nine hours without any contractual breach occurring.

What is the real difference between 99.9% and 99.99% uptime?

The difference is roughly 39 minutes of permitted downtime per month, but operationally it is the difference between human-led and automated recovery. At 99.9% an engineer can be woken, diagnose and restore service within budget. At 99.99% there is no time for a human in the recovery path, so the architecture needs redundant application nodes, automatic database failover and a CDN able to serve content when the origin fails.

What counts as an SLA violation for a website?

An SLA violation occurs when measured availability falls below the contracted percentage over the defined measurement period, or when a response or resolution target for a given severity is missed. Crucially, time excluded by the agreement does not count, so scheduled maintenance, third-party service failures, DNS issues outside the provider's control and client-deployed code changes are usually carved out. Read the exclusions before relying on the headline number.

Does an uptime SLA cover a slow website or a broken checkout?

Not unless the agreement explicitly defines degraded service. Most uptime SLAs are binary and test only whether a page returns an HTTP 200, so a site loading in eighteen seconds, a failing enquiry form or a checkout that does not write orders will still record 100% availability. To cover these, the contract needs response time thresholds, an error rate ceiling, or synthetic transaction checks on the specific journeys that generate revenue.

How often should a website monitoring service check a site?

Enterprise monitoring should poll at 30 to 60 second intervals from multiple external locations, with at least one Australian point of presence and confirmation from a second location before an alert is raised. A five minute check interval cannot detect an outage shorter than five minutes, which makes it unfit for any target above 99.9%. Checks should validate status code, response time and expected page content, not just a TCP connection.

Are service credits worth negotiating?

Service credits rarely approach the commercial cost of an outage, since they are typically capped at a percentage of one month's fee and must be claimed in writing within a short window. Their value is as a signal of how confident the provider is in its own numbers. Spend your negotiating effort on response and restoration commitments and on narrowing the exclusions, because those change what actually happens during an incident.

Working with UnDigital on uptime and SLA commitments

UnDigital writes availability targets against the architecture that supports them, not the other way around. We start with an infrastructure audit, establish what the site can realistically sustain today, and then agree a target with a stated measurement window, named monitoring with client access, capped maintenance windows, and severity-based response and restoration commitments that include application-layer faults rather than excluding them.

Because we run both the infrastructure and the development capability, there is no handoff when the fault turns out to be in the CMS rather than the server. That applies across managed hosting for WordPress, Silverstripe, Drupal and custom applications, whether the infrastructure is ours or your own AWS or Azure environment. If you want to see what your current arrangement is actually measuring before you renegotiate it, independent uptime monitoring is the fastest way to find out.