Your hosting provider promises 99.9% uptime in their Service Level Agreement. But are they actually delivering it? Most website owners have no idea because they rely entirely on their provider's word. That is like asking a student to grade their own exam.
Measuring uptime independently is not just a best practice. It is a business necessity. Without independent data, you cannot verify SLA compliance, claim credits for downtime, or make informed decisions about whether to stay with your current provider.
What SLAs Actually Promise
A Service Level Agreement is a contractual commitment from your hosting provider about the level of service you can expect. The uptime guarantee is usually the headline number, something like 99.9% or 99.95%.
But the details matter far more than the headline. Here is what to look for in the fine print:
How uptime is measured — Some providers measure uptime at the network level (is the server powered on and connected?) rather than the application level (is your website actually serving pages?). Your server can be "up" by their definition while returning 500 errors to every visitor.
What counts as downtime — Many SLAs exclude scheduled maintenance windows, even if that maintenance happens during your peak traffic hours. Some exclude "force majeure" events so broadly that major outages get classified as exceptions.
The measurement period — SLAs typically measure uptime monthly. A provider could have terrible reliability for two weeks, then recover, and still meet their monthly threshold. Your business felt every minute of that two-week stretch.
The credit structure — SLA credits are almost never equivalent to the business impact of downtime. A typical SLA might offer 10% of your monthly bill as credit for missing the 99.9% target. If you pay $50/month for hosting but lost $5,000 in sales during the outage, that $5 credit does not come close to making you whole.
How to Measure Actual Uptime Independently
To hold your provider accountable, you need third-party monitoring that generates its own data, completely separate from your hosting provider's infrastructure.
Here is what independent monitoring gives you:
- Objective data — Your monitoring service checks your site from outside your hosting environment. If your site is down, it records the exact time, duration, and error code.
- Timestamped incident records — Every outage is logged with precise start and end times. This is the evidence you need when filing an SLA claim.
- Historical reports — Monthly and quarterly uptime percentages calculated from actual measurements, not your provider's self-reported metrics.
Sitewake checks your website at regular intervals and logs every response. When your site goes down, you get an alert and a detailed incident record that you can use as documentation. The free plan monitors up to 3 sites, which covers most small business owners' needs for independent verification.
Documenting Incidents for SLA Claims
When an outage occurs, proper documentation is the difference between getting a credit and getting a runaround. Here is what to capture:
- Incident start and end time — Use your monitoring tool's timestamps, not your own estimate of when you noticed the problem.
- Error details — What HTTP status code was returned? Was it a timeout? A 500 error? A DNS resolution failure?
- Screenshots — If you noticed the outage manually, screenshot the error page with a visible timestamp.
- Support ticket timeline — If you contacted your provider during the outage, keep records of when you opened the ticket and how long it took them to respond.
- Business impact — Revenue lost, customers affected, and any downstream consequences. This will not change the SLA credit calculation, but it strengthens your case if you escalate.
Most hosting providers have a specific process for filing SLA claims. You typically need to submit the claim within a set window after the incident, often 30 days. Miss that window and you forfeit the credit regardless of how severe the outage was.
How to Calculate Whether Your Provider Meets Their SLA
The math is straightforward. Take the total number of minutes in the month, subtract the total downtime minutes, and divide by the total minutes.
For a 30-day month (43,200 minutes):
- 99.9% SLA allows 43.2 minutes of downtime
- 99.95% SLA allows 21.6 minutes of downtime
- 99.99% SLA allows 4.3 minutes of downtime
If your monitoring tool recorded 60 minutes of downtime in a month, and your provider promises 99.9%, they have breached their SLA. File the claim with your monitoring data as evidence.
Keep in mind that providers often define the month differently than you might expect. Check whether they use calendar months, billing cycle months, or rolling 30-day windows.
When to Switch Providers
SLA credits are a remediation mechanism, not a solution. If you find yourself filing claims regularly, the credits are not the point. The real question is whether your hosting provider is reliable enough for your business.
Consider switching when:
- SLA breaches are recurring — One bad month can happen to anyone. Three bad months in six signals a systemic problem.
- Credits do not cover your losses — If the business impact of downtime far exceeds the credits, the SLA is not protecting you.
- Communication is poor — A provider that takes hours to acknowledge an outage or provides vague postmortems is unlikely to improve.
- Your needs have outgrown the provider — Sometimes the provider is fine for most customers but cannot handle your specific traffic patterns or requirements.
Before migrating, use your uptime monitoring data to establish a baseline with your current provider. After switching, you will have objective before-and-after data to confirm the new provider is actually better.
The Bottom Line
An SLA is a promise. Independent monitoring is proof. Without your own data, you are trusting your provider to be honest about their own failures. That is not a reasonable foundation for a business-critical service.
Set up independent monitoring, document every incident, file claims when SLAs are breached, and use the data to make informed decisions about your infrastructure. Your website's reliability is too important to take anyone's word for it.