Website Downtime Checklist: What a Small Business Should Check Before Calling the Host

A practical website downtime checklist to help small businesses distinguish DNS, hosting, SSL, WordPress and local network problems. For WordPress-specific outages, also use our WordPress website not loading guide.

For more specific faults, see Cloudflare Error 522/524 troubleshooting, WordPress update recovery and website technical support.

Start your website downtime checklist by confirming the scope

When a website will not load, avoid changing settings immediately. Check whether the problem affects everyone or only one device, network or location. Try mobile data as well as office Wi-Fi and use a private browser. If the site works elsewhere, the web server may be fine and the issue could be local DNS, filtering or caching.

Check the exact error

A timeout, DNS error, SSL warning, 500 error and WordPress critical-error screen point to different layers. Record the message and time before refreshing repeatedly. Screenshots and server logs are more useful than the general statement that the site was down.

Include domain and DNS checks in your website downtime checklist

Confirm the domain has not expired and that its nameservers still point where expected. Recent DNS changes are especially relevant. If the site shows an old server or works intermittently, read the DNS propagation guide before making another change.

Check hosting status and resource limits

Look for provider incidents, suspended services, storage exhaustion or resource limits. A hosting dashboard showing online does not prove WordPress is healthy, but it can quickly reveal account-level problems. Our website-down-but-hosting-online guide covers the next layer.

Separate SSL from availability

A certificate warning means the server may be reachable even though the browser does not trust the HTTPS connection. Check expiry, hostname coverage and certificate provisioning rather than rebuilding WordPress. See SSL certificate troubleshooting.

Investigate WordPress errors methodically

A 500 error or critical-error message may follow a plugin update, PHP change or exhausted memory. Review what changed recently and use logs where available. Avoid disabling random components on a live site without a recovery point. The critical error guide provides a structured process.

Check Cloudflare separately

If Cloudflare is in front of the site, its error code can identify an origin communication issue. A 522 or 524 does not mean the domain is necessarily misconfigured. Use the Cloudflare error guide to distinguish connection and timeout symptoms.

Do not forget business email

If both website and email fail at the same time, DNS or domain changes deserve immediate attention. If only the website is down while Microsoft 365 continues working, that narrows the scope. Avoid replacing the whole DNS zone during a website incident.

Use your website downtime checklist to prepare useful evidence

When contacting support, provide the URL, exact error, start time, networks tested and any recent changes. TempWebz offers website technical support for WordPress, hosting and DNS incidents where the cause is unclear and the priority is restoring service without unnecessary changes.

Keep a website downtime checklist incident record

Write down the first known failure time and the last time someone confirmed the site worked. Include the timezone so the hosting provider can compare the report with logs. Record each affected URL and whether the failure is constant or intermittent. A single screenshot without a time can be difficult to match to a server event.

Separate observations from assumptions. “The contact page returns a 500 error on office Wi-Fi and mobile data” is useful evidence. “The host is broken” is a conclusion that still needs testing. Note any deployment, renewal, DNS edit or plugin update near the start of the incident, but do not assume timing alone proves the cause.

Use the right diagnostic help

Ask the host to check service availability and relevant server logs. Ask the website developer to investigate application failures. WordPress provides official debugging guidance for technical teams; use a staging environment or suitable backup before changes, and do not expose private debug information to visitors.

If several providers are involved, give them the same concise incident record. Keep one person responsible for coordinating changes. Otherwise one provider may alter DNS while another changes the origin server, making the results harder to interpret. Request a clear description of each proposed action and how it can be reversed.

Close your website downtime checklist with a visitor test

Once the site responds again, test more than the homepage. Open an affected page, follow a normal navigation path and submit a clearly marked test enquiry. Confirm that the message reaches the intended inbox. If the site accepts bookings or payments, use the appropriate test workflow and check for missing or duplicated records.

Repeat the check from a second network if the incident involved DNS or intermittent access. Record the recovery time and any continuing errors. A provider’s resolved status notice is useful context, but the business still needs evidence that its own customer journey works.

Finally, document the confirmed cause, the repair and any follow-up action. If the cause remains uncertain, say so rather than closing the record with a guess. Arrange monitoring that checks the important page or workflow, and review recurring incidents together to identify a pattern.