How to Prove Website Downtime to Your Hosting Provider

Your site went down. You lost revenue, customers got errors, and you've submitted a support ticket to your hosting provider. Their response: "We see no issues on our end."

This is one of the most frustrating situations in web operations — and it's almost always resolved by evidence, not arguments. Hosting providers respond to data. Vague claims of "my site was down" get vague responses. Timestamped HTTP logs from multiple locations get escalated.

Here's how to build and present an airtight downtime case.

Why Providers Say "We See No Issues"

Hosting providers aren't always lying or being evasive. Their monitoring typically looks at server-level health: is the machine running, is the web server process alive, is there a network path to the server. All of these can be fine while your site is still down from a user's perspective.

Common scenarios where the provider's view differs from reality:

• Application errors (500s) — The server is up, but your app is crashing. The server monitoring shows green; users see errors.
• Database connectivity failures — The web server responds, but database connections fail. Your app returns errors; server uptime is 100%.
• DNS issues — The server is up; DNS isn't resolving correctly. Monitoring from inside their network works; external users can't reach the site.
• Single-location failures — A routing issue affects some users but not the path the provider monitors from.

This is why evidence from external monitoring, from multiple locations, is the only kind that definitively proves user-facing downtime.

What Evidence to Collect

1. HTTP Response Code Logs with Timestamps

The most useful evidence is a timestamped log of every HTTP request to your site with the response code received:

2026-03-15 14:23:01 UTC  GET https://yourdomain.com  200  OK  847ms
2026-03-15 14:24:01 UTC  GET https://yourdomain.com  503  Service Unavailable  12043ms
2026-03-15 14:25:01 UTC  GET https://yourdomain.com  503  Service Unavailable  timeout
2026-03-15 14:26:01 UTC  GET https://yourdomain.com  503  Service Unavailable  timeout
...
2026-03-15 15:47:01 UTC  GET https://yourdomain.com  200  OK  923ms

This format is immediately legible to a hosting support team and impossible to dispute — it shows exactly what was returned at exactly what time.

2. Multi-Location Confirmation

A response code log from a single location could theoretically be a network issue between that location and your server. Multi-location checks remove this argument:

2026-03-15 14:24:01 UTC  Frankfurt  503
2026-03-15 14:24:01 UTC  New York   503
2026-03-15 14:24:01 UTC  Singapore  503
2026-03-15 14:24:01 UTC  Sydney     503

If four geographically distributed monitoring nodes all see 503, the problem is at your server, not in a network path.

3. Response Time Data

Slow responses often precede complete downtime and can reveal server-level problems like database overload:

14:15  842ms  200
14:18  2341ms  200
14:20  8923ms  200
14:22  timeout  503
14:24  timeout  503

The degradation pattern shows the server struggling before it stopped responding entirely.

4. Error Message Details

When you can, capture the exact error message or response body, not just the HTTP code. "503 Service Unavailable" from a load balancer that can't reach your app server is different from a 503 from your application returning a database connection error. The specific error body often implicates the exact component.

Setting Up Monitoring Before You Need It

The problem with proving downtime retroactively is that you can only prove it if you were monitoring before it happened. Screenshots of your browser during an outage are not the same as timestamped monitoring logs — they can be dismissed as a local network issue, a browser cache problem, or simply an error in your reporting.

Continuous monitoring with timestamped logs creates an audit trail that exists independently of whatever you say happened.

Domain Monitor checks your site every minute from multiple global locations and stores the full history of every check — response codes, response times, and check location. When downtime occurs, you have a complete, exportable log of exactly what happened and when. Create a free account and set it up before you need the evidence.

How to Present a Downtime Case

Format Your Evidence

Don't dump raw logs at your hosting provider — format the evidence to make their job easy:

Summary:

We experienced a service outage from 14:23 UTC to 15:47 UTC on 15 March 2026 — a total of 1 hour 24 minutes. During this period, our uptime monitoring service recorded 503 responses from checks originating in Frankfurt, New York, Singapore, and Sydney, confirming this was not a local network issue.

Evidence:

1. Attach the full monitoring log (CSV or table format)
2. Include a screenshot of your monitoring dashboard showing the outage period
3. Note the first and last failure timestamps precisely

What you're asking for:

We are requesting a review of server logs for this period to identify the root cause, and an SLA credit for the downtime under our hosting agreement.

Cite Your SLA

If your hosting plan includes an uptime SLA, reference it specifically. Most managed hosting providers guarantee 99.9% uptime, which allows for no more than 8.7 hours of downtime per year. An incident of 1h24m downtime is a significant fraction of that annual allowance.

Look for:

• The specific SLA percentage in your contract
• The credit calculation methodology (usually expressed as a percentage of monthly fee per hour of excess downtime)
• The claim submission process and deadline (many SLAs require claims within 30 days)

Escalate If Needed

If first-line support dismisses your evidence, escalate:

1. Request escalation to a senior engineer — First-line support may not be able to read server-side logs. Ask for someone who can correlate your monitoring timestamps with server access logs.

2. Reference the specific logs you want them to check — "Can you check the Apache/Nginx error logs for our server between 14:20 and 15:50 UTC on 15 March?" gives them a specific task rather than a vague request to "look into it."

3. Include the error messages — If your monitoring captured specific error body content (502 Bad Gateway from nginx, database connection refused, etc.), include it. These are often fingerprints of specific infrastructure failures.

What Won't Work

Browser screenshots — Easy to dismiss as local issues, cached errors, or user error.

"I noticed my site was slow" — Without timestamps and HTTP codes, this is anecdotal.

Social media complaints from users — Useful as corroboration but insufficient on their own.

Your own server error logs — These are valuable for root cause analysis but hosting providers may argue they've been modified. External monitoring logs are more authoritative because they come from a third-party system outside your control.

After the Incident

Once the downtime is resolved and you have the root cause:

1. Document it in your incident log — What failed, when, why, and how long it took to resolve.

2. Submit your SLA credit claim promptly — Most providers have deadlines for claims. Don't wait.

3. Review what monitoring changes would have detected it earlier — If this was a database issue, do you have a health check endpoint that tests database connectivity? If it was a DNS issue, do you have DNS monitoring in addition to HTTP monitoring?

See uptime monitoring best practices and how to write a post-incident report for follow-up steps after significant downtime events.

Also in This Series

• How to Monitor Stripe Webhooks and Checkout Flows
• How to Monitor MySQL Availability, Slow Queries, and Replication Lag
• How to Monitor PostgreSQL Performance and Connection Issues
• How to Monitor Queue Workers on Laravel, Node.js, and Python Apps
• Why Your Domain Points to the Wrong Server
• DNS Propagation Taking Too Long? What to Check First
• How to Rotate SSL Certificates Without Breaking Your Site
• Let's Encrypt Renewal Failed: Common Causes and Fixes
• Internal vs Public Status Pages: When You Need Both
• How to Reduce Alert Fatigue Without Missing Real Incidents
• Best Status Page Tools for SaaS Startups