Website Down? A Hosting, DNS and Application Troubleshooting Checklist
Save the evidence before changing the configuration. Record the affected URL, error message, time and timezone, and what customers cannot do. A website outage can involve the visitor’s connection, DNS, certificates, a CDN, hosting or the application. Changing all of them at once makes both recovery and diagnosis harder. A current example is the October 2026 DNS root key rollover: a stale validating resolver can make healthy signed domains appear unreachable.
Confirm the scope of the failure
Try the affected public page from another connection or an independent monitor. Compare the homepage with the actual failed route: product page, login, form or checkout. Use authorized access for private pages. A cached homepage returning successfully does not prove that database writes or payments work.
Check the official status pages for the host and any relevant CDN, payment or email service. Save the incident reference and observation time. An acknowledged incident is useful context; a green status page does not rule out an account-specific or application-specific problem.
| Check | What it establishes | What it can miss |
|---|---|---|
| DNS or browser certificate error | Record the exact hostname and browser message; ask the DNS or certificate owner to verify the configuration. | The cause cannot be established from a screenshot alone. |
| HTTP error or timeout | Save the URL, code, time, timezone and any request identifier. | The visible intermediary may not be the component that failed. |
| Homepage works; checkout or login fails | Check application logs and the relevant integration with its owner. | Public page caching can hide a failing application. |
| Only one connection fails | Compare another network and monitoring location. | A local problem and a wider intermittent incident can coexist. |
Understand the error before choosing a fix
For Cloudflare-proxied sites, its 522 documentation describes timeouts between Cloudflare and the origin server. Listed causes include blocked or rate-limited Cloudflare traffic, an unavailable or overloaded origin, and an incorrect origin IP. The code narrows the investigation; it does not by itself prove that you need a larger hosting plan.
A 524 error means the origin connection succeeded but the response or write did not complete within the applicable timeout. Long-running work and origin overload are possible causes. Ask the host or administrator to correlate the request with logs and resource use. Use the hosting limits guide when capacity evidence points there.
Cloudflare’s 5xx troubleshooting guidance asks for the exact code, time with timezone and affected URL, and notes that logs from proxies, firewalls, caches or load balancers can matter too. Include a Ray ID if shown. These distinctions apply to Cloudflare errors; other platforms have their own documentation.
If an application workflow started failing after a component change, use the controlled plugin conflict test to collect reproducible evidence in an appropriate test environment.
Give support a concise incident record
Include the first observed failure, affected workflows, example URLs, repeated-check results, recent deployments or configuration changes, status-page references and relevant request IDs. Share sanitized logs through the provider’s supported channel. Keep customer details, credentials and payment information out of public screenshots and tickets.
Confirm which person can authorize changes. If the blocker is account access, follow the account recovery checklist. Ask the responder to identify the failing layer and the next reversible action, then record that action and its result.
Use the hosting support-ticket checklist to organize evidence and escalation. Check the support scope when investigation identifies work for a developer or software vendor.
If the host has flagged harmful activity or you have evidence of unauthorized changes, use the malware recovery checklist before choosing a restore. Keep the provider incident reference and involve the qualified responder.
Choose rollback or restore with current data in mind
A failed deployment may justify a controlled rollback after the owner reviews the change. A restore is a different operation: it can replace newer content, orders or account activity. Check backup retention, the available recovery point and the data gap before choosing it. Use the restore rehearsal guide to understand what has actually been tested.
For a store, reconcile orders and payments with the gateway and fulfilment records; see WooCommerce order recovery. Avoid repeating a payment or background job until its external result is known. A timeout can leave the business outcome uncertain.
Verify recovery and close the incident
Repeat the failed workflow, check relevant messages and scheduled jobs, and observe the site through the configured monitor. Record the recovery time, remaining problems and follow-up owner. Use the uptime monitoring checklist to improve detection. Recovery is established by the relevant result, not just a successful login to the hosting dashboard.
Use the symptom to choose a narrower investigation
Once the failing request is captured, use the 403 checklist for denied access or the 502/504 checklist for gateway failures. A WordPress fatal-error message belongs in the critical-error workflow. Keep the wider incident record open: repairing one layer does not establish that orders, messages and background work recovered.
Sources and scope
Cloudflare documentation checked October 5, 2026. This is HRL’s general response checklist. It does not diagnose a particular site’s outage or report a recovery performed by HRL.