Guides

Understanding a monthly uptime report: what the numbers mean

A practical guide to interpreting uptime reports: the difference between server and website uptime, false positives, and when your SLA entitles you to a refund.

UptimeMag editorial team · 25 October 2026 · 4 min read

Cern datacenter

Anyone managing a website or VPS will eventually receive a monthly uptime report from their hosting provider. Typically it's a PDF or webpage showing a percentage in large print (99.8%, 99.95%, sometimes 100%) with just a few details. Understanding whether that number represents a problem requires knowing three things: what it actually measures, when it's misleading, and when it entitles you to a refund.

Server uptime and website uptime are not the same

The report from your provider almost always measures infrastructure uptime, not website uptime. The distinction is crucial: the server can be powered on and reachable on the network, yet your website still fails to load due to a CMS error, a plugin timing out, an expired SSL certificate, or a full database. In these cases, your provider's report shows 100%, because from their perspective the service worked: they delivered CPU, RAM and connectivity. The fact that your website on top wasn't responding is an application problem, not an infrastructure one.

A concrete example of this distinction can be found in VHosting's SLA, which for dedicated servers specifies that monitoring covers gateway operation and hardware for connectivity, while the customer's server itself is not monitored directly unless the customer purchases a proactive monitoring system. If you want to know whether your site was genuinely reachable, you should therefore combine your provider's report with an external uptime monitor (uptime checker) that tests your public URL, not just a ping to the server.

How much downtime is "normal" for each SLA threshold

The number alone means little if you don't know how many minutes it translates to. The calculation is straightforward: downtime = period duration × (1 − SLA/100).

Guaranteed uptime Allowable downtime per month Allowable downtime per year
99% 7 hours 18 minutes 3 days 15 hours
99.5% 3 hours 39 minutes 1 day 19 hours
99.9% 43 minutes 8 hours 45 minutes
99.95% 21 minutes 4 hours 22 minutes
99.99% 4 minutes 52 minutes
99.999% 26 seconds 5 minutes

If your report shows 99.92% on a contract with 99.9% SLA, there is no violation: the allowed margin was not exceeded. Problems only start when actual uptime falls below the contractual threshold, not below 100%.

False positives in reports

Many reports conflate "technical" downtime with "perceived" downtime. The following count as false positives, according to terms published by various providers:

  • scheduled maintenance communicated in advance, which many contracts exclude from the calculation;
  • outages caused by third-party software installed by the customer: ClameHost's SLA specifies it does not cover the operation of third-party software installed on servers, including scripts that cause application issues;
  • interruptions due to causes external to the provider's network (DDoS attacks targeting third parties, external DNS problems, user errors).

If you receive a report showing lower uptime, always check the footnotes or "exclusions" section of your contract before disputing the figures: the provider has often already deducted scheduled maintenance from the final calculation.

When it makes sense to claim a refund

A refund (almost always called a "service credit") only triggers when the uptime measured in the period falls below the threshold stated in your SLA, and the credit percentage depends on how far below it goes. Here's how some providers that publish their full terms calculate it.

Provider Guaranteed threshold Refund offered
Serverplan (network) 99.95% monthly 10% refund if not met
VHosting per product specification 10% refund up to 97.5%, 20% below 97.5%
FastNom 99.9% annually 0% (99.9%–100%) up to 100% refund below 90%, in tiers
ClameHost 99.9% credit from 10% (98%–99.8%) to 20% (95%–97.9%), tiered

In nearly all cases, credit is not cash but a discount on renewal: FastNom, for example, specifies that the refund can only be converted to a discount on renewal of your hosting service or purchase of another service. It's worth knowing this before opening a support ticket expecting a bank transfer.

How and when to request it

The request must be made within a specific window, which varies by provider: FastNom requires all requests to be submitted within 5 days of the incident, or rights are forfeited. Other providers, especially international ones, use wider windows (30 days is common for large managed hosts). The practical advice is simple: as soon as your monthly report shows uptime below your contractual threshold, save a screenshot of the report, find the exact date of the outage in your external monitor's logs, and send your credit request before the deadline specified in your contract expires—and always review your contract first, as terms vary significantly between providers.

Written with the help of artificial intelligence and checked by the editors (EU AI Act, art. 50).