Uptime Guarantees Exposed What Hosts Actually Promise

An uptime guarantee is not a promise that your site will stay up. It is a promise about how the host will measure availability, and more importantly, it is a promise about what you get when that measurement falls short. The phrase uptime guarantee explained usually means reading the fine print of a service level agreement, or SLA, and understanding that the number you see advertised, often 99.9 percent, is a target for billing credits, not a warranty of uninterrupted service.

When a host says they offer a 99.9 percent uptime guarantee, they are defining a measurement window, typically a calendar month, and a method for checking your server. The host runs a monitoring probe from outside their own network. That probe sends a TCP connection request to your server's IP address on a specific port, usually port 80 for HTTP or port 443 for HTTPS. If the probe gets no response within a timeout, often five seconds, that attempt counts as downtime. The host sums all failed attempts over the month, divides by the total number of attempts, and subtracts from 100 percent to get the reported uptime.

You can run the same kind of check yourself from a terminal. A simple loop with curl and a timestamp gives you a raw view of reachability. The command below checks every 60 seconds and logs failures to a file.

while true; do
  code=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 5 https://your-site.example)
  if [ "$code" != "200" ]; then
    echo "$(date -u +%Y-%m-%dT%H:%M:%SZ) status=$code" >> /var/log/uptime-check.log
  fi
  sleep 60
done

That log will show you gaps, but it will not match the host's numbers. The host's probe sits on a different network path, uses a different timeout, and may ignore application errors. A 500 response from your web server still counts as "up" for the host if the TCP handshake completes. Your own check counts it as a failure. This discrepancy is the first thing to understand about any guarantee.

What the SLA Actually Covers

Read the SLA document, not the marketing page. The marketing page says "99.9 percent uptime." The SLA defines the measurement period, the excluded events, and the credit formula. Excluded events are the loopholes. Scheduled maintenance is almost always excluded, and the host defines what "scheduled" means. Some hosts give you 24 hours notice, others give you none. Emergency maintenance, which is often vaguely described as "necessary to preserve service integrity," is also excluded. Network issues outside the host's direct control, such as a backbone outage or a DDoS attack, are typically excluded as well.

The credit formula is where the guarantee gets real. A common structure is a sliding scale. For example, if monthly uptime falls below 99.9 percent but above 99.0 percent, you get a credit equal to 5 percent of your monthly fee. Below 99.0 percent, the credit might rise to 10 percent. Below 95 percent, you might get 30 percent. The credit is applied to your next invoice, not refunded to your credit card. You must also file a claim manually, usually within 30 days of the end of the month, and you must provide your own monitoring logs as evidence. The host's monitoring data is the final arbiter, and you rarely get to see the raw probe logs.

How to Verify the Guarantee Yourself

Do not trust the host's dashboard. Set up external monitoring from at least two locations that are not on the host's network. A free or low-cost monitoring service that checks from multiple regions is better than a single script on your own server, because your server shares the network path with the host. If your server is down, your script is down too, and you have no record.

For a more precise check, you can look at the HTTP response headers. The Date header and the Server header tell you the time and the software, but they do not tell you about the underlying infrastructure. What you want is the Via header or the X-Cache header if a CDN or proxy sits in front. That tells you whether the host is serving your site directly or from a cached copy. A host that serves a stale cached page during an outage will still report 100 percent uptime, because the probe gets a 200 response from the cache.

You can also check DNS resolution history. If the host moves your site to a different IP during an incident, your own records will show a gap. The command below queries the authoritative nameserver for your domain and logs the answer.

dig +short your-site.example A @ns1.example-host.com >> /var/log/dns-a-record.log
cat /var/log/dns-a-record.log | sort | uniq -c

That output shows you how many times each IP address appeared. If you see more than one IP over a month, the host changed your endpoint. That change is not necessarily downtime, but it is a sign that the host is doing failover, and failover events often correlate with incidents that the SLA excludes.

What Recourse You Actually Have

The credit is the only recourse. You cannot sue for lost revenue based on an uptime guarantee, because the SLA explicitly limits liability to the credit amount. The host's terms of service will state that the SLA is the sole remedy for availability failures. That means if your ecommerce site loses a day of sales because the host's network went down, your compensation is a small percentage of your hosting fee, not a percentage of your lost revenue.

To make a claim, you need to document the outage window precisely. Your monitoring log should show the start time, the end time, and the error type. The host will compare that to their own probe data. If they claim the outage was due to an excluded event, such as a DDoS attack, ask for the traffic logs or the upstream provider's advisory. Many hosts will not provide those, and the SLA does not require them to. Your only leverage is the threat of leaving, and that leverage works only if you have a backup plan.

What to Look For in a Host's Guarantee

When you compare hosts, look for three things in the SLA. First, the definition of downtime. Does it include application-level failures, or only network reachability? Second, the credit threshold. A host that offers a credit only below 99.0 percent is effectively promising nothing, because most hosts stay above that even with a few hours of downtime per month. Third, the claim process. A host that requires you to file within 7 days and provide logs from a third-party monitor is harder to claim against than one that accepts your own server logs.

Also check the maintenance window. Some hosts schedule maintenance during off-peak hours and exclude it from the SLA. Others do not exclude it, which is better for you. The difference matters because a host that does rolling kernel updates every week can accumulate several hours of excluded downtime per month, and you will never see a credit.

Uptime Guarantee Explained in Practice

The practical takeaway is that an uptime guarantee is a pricing mechanism, not a reliability promise. It exists to cap the host's liability and to give you a small discount when things go wrong. The real reliability of your site depends on your own architecture: redundant servers, a CDN, and a failover plan. The guarantee is the floor, not the ceiling.

Your next step is to read the SLA of your current host and write down the exact credit formula and the excluded events. Then set up external monitoring if you have not already. If the SLA has too many exclusions or a credit formula that starts too low, that is a signal to plan a migration. Do not wait for an outage to discover that your guarantee is worth less than a coffee.