99.9 uptime explained, downtime per month and how SLAs measure it

Allowed downtime is the period length multiplied by the share that is not up. The table uses a 24 hour day, an average month of 30.44 days (365.25 divided by 12) and a 365 day year. Figures are rounded.

Each extra nine cuts the allowance by a factor of ten. Going from 99.9% to 99.99% means the whole month of incidents, deploys gone wrong and DNS mistakes has to fit into about four and a half minutes. That is a different engineering budget, not a small improvement.

Contracts often say "per calendar month". February has 28 days and July has 31, so the same percentage allows about 40 minutes 19 seconds in February and about 44 minutes 38 seconds in July at 99.9%. The difference is small, but it shows why the contract should say how the period is defined. A rolling 30 day window, a calendar month and a quarter all produce different numbers for the same incidents.

The window is the period over which uptime is calculated and compared with the target. A monthly window forgives a bad day if the rest of the month is clean. A daily window does not. Most SaaS agreements use a calendar month because it lines up with billing and credits.

• Calendar month. Simple, aligns with invoices, the most common choice.
• Rolling 30 days. Smooths month boundaries, useful for internal targets.
• Quarter or year. Very forgiving, a single long outage barely moves the number.

A short outage at 23:55 on the last day of the month can split across two windows. Good reports show the incident with its real start and end time, so nobody argues about which month it belongs to.

Almost every SLA excludes scheduled maintenance, usually with a notice period such as 48 or 72 hours and sometimes a cap on total maintenance hours per month. That is fair, because planned work announced in advance is not a surprise. It also means the headline uptime figure can look better than the customer experience.

• Define how much notice counts as scheduled.
• Cap maintenance time per month, otherwise any outage can be relabeled.
• Publish maintenance on a status page, so the exclusion has a record.
• Keep checks running during maintenance and report raw availability next to the SLA figure.

In UptimePilot, maintenance windows pause alerts for the affected monitors, while checks continue, so both the SLA number and the raw number stay available in the report.

Contracts also tend to exclude outages caused by the customer, force majeure events and failures of third party services outside the provider's control. Read these carefully. If a payment gateway or an upstream API is a hard dependency of your product, decide in advance whether its outages count.

"Down" is not always binary. A site can load while login fails, or the API can answer while one region times out. An SLA has to say which of these count.

• Full outage. Every request fails or times out. Clearly down.
• Partial outage. One feature or endpoint fails while others work. Some agreements count it fully, some proportionally, some not at all.
• Degraded performance. Responses arrive but very slowly. Many agreements set a response time threshold above which a check counts as failed.
• Regional outage. Users in one region cannot connect. Whether it counts depends on how many regions must fail.

A practical approach is to define the SLA on the endpoints that represent the core product, such as the login page and the main API health route, with a timeout that counts slow responses as failures. Our website performance monitoring page covers response time thresholds and percentiles.

Uptime is measured by sampling. A monitor that checks every minute sees the service 1,440 times a day. Anything that happens between two checks is invisible. A 20 second blip can start and end between checks and never appear in the record, while a single failed check can, if counted naively, add a full minute of downtime that was really a few seconds.

• A 1 minute interval cannot see 20 second blips reliably, and it measures outages with up to about a minute of error at each end.
• A 30 second interval halves that error and catches shorter incidents.
• At 99.99% the monthly allowance is about 4 minutes 23 seconds. With 1 minute checks, a few sampling errors use a large part of it. Tight targets need short intervals.
• At 99.9% the allowance of about 43 minutes is large enough that 1 minute checks measure it well.

UptimePilot checks every minute on Starter and every 30 seconds on Team, Business and Enterprise.

A failed check from one location might be a network issue between the probe and your host rather than a real outage. Counting it as downtime understates your uptime. Ignoring all failures overstates it. Confirmation from a second region resolves this. UptimePilot checks from US East and EU Central and marks a monitor down only when a second region confirms the failure. The incident then runs from the first confirmed failure to the first successful check, and that period is what goes into the report.

An SLA is a promise with a price attached. When uptime falls below the target in a window, the customer receives a credit, usually a percentage of the monthly fee for that service. A typical structure has tiers.

These tiers are a common pattern, not a standard. Credits are normally the sole remedy, have to be requested within a set period and are capped at the monthly fee. For the provider, the more important cost is trust. A customer who has to calculate their own credit from a spreadsheet will remember that more than the credit itself.

The strongest SLA is one the customer can check. A monthly report with uptime percent, a list of incidents with start and end times, and response time percentiles answers most questions before they are asked. Teams on UptimePilot get uptime and response time reports on every plan and a monthly SLA PDF from Team upward. Agencies on Business send white-label client reports. See uptime monitoring service for what each report contains.

Promise what your setup supports, then measure it independently. A single server with one database and manual deploys can reasonably target 99.5% to 99.9%. Reaching 99.95% and above usually needs redundancy across instances, zero downtime deploys and fast automated failover. Promising 99.99% without that is a promise to pay credits.

• Measure for a full quarter before you write a number into contracts.
• Set the internal target one step above the contractual one.
• Count every confirmed incident, including the short ones, in internal reports.
• Review incidents monthly and fix the causes that repeat.