How to Verify a Hosting Uptime Claim

A hosting uptime test can show whether a URL responds at the time of the check, but it cannot by itself confirm a provider’s advertised percentage or prove an SLA breach. To verify the claim, read the provider’s SLA, define what counts as success, monitor the real public HTTPS address from multiple locations for the same measurement period, and compare only matching records.

Start with the provider’s definition#

Find the host’s SLA or terms, not only its sales page. Record:

• The exact service covered, such as a public website, control panel, server, or network.
• The URL, path, and protocol included in the measurement.
• The measurement period and geographic scope.
• Which response codes, redirects, response content, and certificate conditions count as success.
• Maintenance exclusions, incident exclusions, and other exceptions.
• The required claim process and any remedy for missing the commitment.

Availability can mean the percentage of time a service is usable or the proportion of successful requests. These definitions can produce different results. An SLO is a target; an SLA is a user-facing agreement that may attach consequences to missing that target. The contract may also measure a narrower service or apply exclusions that an independent test does not. See the Google Cloud reliability guide and Google SRE’s explanation of service-level objectives.

Run an external, multi-location check#

Use an independent monitoring service or uptime-checking tool to test the site’s real public HTTPS address and a relevant path from several geographic locations. A one-time request is only a snapshot; monitoring over the provider’s stated measurement period gives you a record that can be compared with the claim.

Define the success rule before collecting results. The check may need to:

• Follow redirects and validate the final response.
• Require a specific HTTP status code.
• Look for expected response text.
• Confirm that the TLS certificate is valid.
• Record the timestamp, location, URL, response, and failure reason.

Public HTTP checks do not necessarily load every page asset or run JavaScript. They test the response from the endpoint, not the complete browser experience. If the concern is a slow or broken page rather than an unreachable URL, a separate browser or page-performance test may be needed. Google Cloud’s public uptime check documentation describes these kinds of checks and their limits.

Review failures before counting them#

HTTP status codes provide useful evidence, but a code alone does not identify the cause:

• 2xx indicates a successful response.
• 3xx indicates a redirection; inspect the final response if redirects are part of the test.
• 4xx indicates a client-side request error.
• 5xx indicates a server-side or upstream failure.

A 404 may mean the test used the wrong path. A 503 can occur during maintenance or overload. A 504 indicates a gateway timeout. Check the URL, redirect chain, response rule, certificate result, timestamp, and other monitoring locations before classifying an event. One failed check does not prove that the entire hosting service was unavailable. If only one location reports a failure, record it as a location-specific observation for investigation rather than automatically treating it as a site-wide outage. The MDN HTTP status code reference explains the status-code classes and examples.

Calculate only what you measured#

For a check-based record, use:

Observed availability = successful checks ÷ total checks × 100

State the success rule and time window before calculating. This result describes the checks that actually ran; it does not directly measure every second between checks. A failed check may represent an unavailable endpoint, a certificate failure, a timeout, a wrong path, or another condition defined by your rule.

Compare the calculation with the provider’s SLA only when the service, URL or scope, measurement period, geographic coverage, exclusions, success criteria, and measurement method align. Otherwise, call the result an observed check result, not a contractual uptime result.

Keep evidence for a claim#

Save the monitoring report and timestamps, along with the tested URL and path, locations, protocol, status codes, redirect results, response-content result, certificate result, total checks, successful checks, and calculation. If the provider’s SLA has a claim deadline or required evidence, follow those terms.

A careful report should say what was tested, when and where it was tested, what counted as success, and what was observed. It should separately state whether the available evidence satisfies the contract’s rules for an SLA breach. The Google SRE service-level objective guidance provides the distinction between a performance target and a service agreement.