When a website stops loading, the first challenge is identifying whether the cause is DNS, hosting, an application change, an expired certificate, or an external dependency. This uptime and downtime response plan gives you a repeatable workflow for confirming an outage, narrowing the cause, contacting the right support channel, communicating clearly, restoring service, and improving monitoring after recovery.
Overview
A website outage is not always a complete failure. Visitors may see a timeout, a DNS error, a certificate warning, a server error, a blank page, or a site that works for some people but not others. Treating every symptom as a hosting failure can delay recovery, while making changes before collecting evidence can make diagnosis harder.
A practical website outage response plan has five stages:
- Confirm the problem: Check whether the issue is reproducible and whether it affects multiple networks or locations.
- Classify the symptom: Record the exact error, affected URL, time, browser, and response code.
- Check the likely layers: Review domain and DNS records, hosting resources, server logs, application changes, SSL configuration, and external services.
- Recover carefully: Roll back a recent change, restart an appropriate service, restore a verified backup, or escalate to hosting support.
- Document and improve: Record the timeline, cause, actions, and follow-up tasks so the next incident is faster to handle.
Keep this plan accessible to everyone responsible for the site. It is especially useful before a deployment, marketing campaign, domain renewal, or hosting migration. For a broader monitoring setup, see the Website Uptime Monitoring Guide.
What to track
Availability and response behavior
Use hosting uptime monitoring to check the homepage and, where appropriate, one or two important paths such as a login page, checkout, contact form, or API endpoint. A single check does not describe the whole site. Track:
- Successful and failed checks, including the date and time zone.
- HTTP status codes and whether redirects complete as expected.
- Connection failures, DNS resolution failures, TLS or certificate errors, and timeouts.
- Response time trends, not only whether a page eventually loads.
- The monitoring location or network used for each check.
Monitoring has limitations. A basic HTTP check may report success even when a key database operation, payment flow, or JavaScript feature is broken. Conversely, a check from one location may fail because of a local network path while visitors elsewhere can still reach the site. Use more than one monitoring location when the site is important, and test critical user journeys separately from simple availability.
Domain, DNS, and certificate details
Record the domain registrar, DNS provider, authoritative nameservers, renewal contact, and the intended records for the website and email. During an incident, confirm that the domain resolves to the expected destination and that recent DNS changes have not introduced an incorrect address, missing record, or unexpected proxy behavior.
Also track the certificate expiration date, covered hostnames, and renewal method. If the site loads over HTTP but browsers show an HTTPS warning, investigate the certificate, server configuration, redirect rules, and mixed content separately. The SSL Certificate Errors Explained guide covers this class of problem in more detail.
Hosting, application, and dependency signals
Keep a record of hosting resource usage and recent changes. Depending on your plan and control panel, useful signals may include disk space, memory pressure, CPU load, database availability, process limits, error logs, access logs, deployment history, and backup status. For managed WordPress hosting, note recent plugin, theme, core, PHP, or configuration changes. For VPS or cloud hosting, include operating system updates, firewall rules, web server configuration, container status, and scaling events.
List external services that can affect the site, such as DNS providers, content delivery networks, payment platforms, email providers, authentication services, and third-party scripts. A page may appear unavailable because it is waiting on a failing dependency even though the origin server is healthy.
Symptom-to-cause troubleshooting table
| Symptom | Likely areas to check | Useful next step |
|---|---|---|
| DNS or server-not-found error | Nameservers, A or AAAA records, DNS changes, domain status, local resolver cache | Check resolution from multiple networks and compare results with the intended DNS records. |
| Connection timeout | Hosting availability, firewall rules, overloaded resources, network path, origin server | Test from another location, review monitoring history, and inspect hosting diagnostics or support notices. |
| 403 Forbidden | File permissions, access rules, security software, firewall or CDN settings | Review recent rule changes and server or security logs before changing permissions. |
| 404 Not Found | Wrong URL, rewrite rules, deployment, missing files, application routing | Test the homepage and known working paths; compare the affected URL with the deployment record. |
| 500, 502, 503, or 504 error | Application failure, upstream service, PHP or process limits, database, reverse proxy | Capture the timestamp, inspect application and server logs, and escalate with the exact error details. |
| HTTPS warning or redirect loop | Certificate coverage, renewal, proxy mode, redirect rules, mixed content | Check the certificate hostname and recent HTTPS or DNS changes before editing redirects. |
| Works for some visitors only | DNS propagation or split results, caching, CDN, regional routing, device or network differences | Compare locations, resolvers, browsers, and direct origin behavior where supported. |
Cadence and checkpoints
Reliability improves when checks happen before an emergency. Use this cadence as a starting point and adapt it to the site’s risk and change frequency.
During an outage
- Open an incident note and record the first alert time.
- Reproduce the issue from a separate network or device. Save screenshots, URLs, status codes, and timestamps.
- Check the monitoring dashboard from multiple locations and look for a matching hosting or infrastructure notice.
- Review recent deployments, DNS edits, certificate changes, plugin updates, and account activity.
- Inspect accessible logs and control-panel diagnostics. Avoid deleting logs or making several unrelated changes at once.
- Contact hosting support through the documented urgent channel. Include the domain, affected paths, timestamps with time zone, observed errors, test locations, and actions already taken.
- Publish a concise status update if customers or internal users are affected. State what is known, what is being investigated, and when the next update will be provided.
Do not assume that restarting services or restoring a backup is always the safest first action. Preserve evidence, verify the backup’s date and scope, and use a restoration procedure appropriate to the platform. The Website Backup and Recovery Plan can help establish those procedures in advance.
Monthly and quarterly checkpoints
- Monthly: Review alerts, recurring errors, slow periods, failed synthetic checks, disk usage, backup completion, and certificate or domain renewal reminders.
- Quarterly: Test a backup restoration in a safe environment, review monitoring coverage, verify support contacts and account access, and rehearse the outage checklist.
- After every deployment or DNS change: Test the homepage, key user journeys, redirects, HTTPS, forms, email where relevant, and monitoring alerts.
- Before a campaign or traffic increase: Confirm capacity assumptions, caching behavior, application dependencies, and an escalation path with the hosting provider.
How to interpret changes
Look for patterns rather than treating every failed check as a separate incident. A short failure from one monitoring location may indicate a local route or probe issue. Simultaneous failures across locations, especially with DNS errors or timeouts, suggest a broader infrastructure or configuration problem. Repeated 5xx responses after a release point toward the application, database, or deployment; repeated slow responses before failures may indicate resource pressure or a dependency becoming unreliable.
Compare the incident with the change log. Timing is often more useful than assumption: if the site failed immediately after a DNS edit, certificate renewal, plugin update, firewall change, or migration step, investigate that change first while still checking independent causes.
Separate availability from performance. A site that returns a successful status but takes too long to become usable may be operationally unavailable to real visitors. Track response time and critical transaction success alongside basic uptime. If resource usage is regularly approaching plan limits, evaluate configuration and optimization before selecting a larger service. The guide on reducing website hosting costs without slowing your site provides a useful review framework.
Finally, read uptime guarantee terms carefully. A hosting uptime guarantee may define eligible services, measurement methods, exclusions, maintenance windows, notification deadlines, or service-credit procedures. Treat the guarantee as a contract detail, not as a substitute for independent monitoring, backups, and an internal recovery plan.
When to revisit
Revisit this plan at least monthly for alert review and quarterly for a deeper reliability check. Update it immediately after a major infrastructure change, hosting migration, domain transfer, DNS provider change, security incident, backup-system change, or recurring outage. It should also be reviewed before a high-traffic launch and whenever responsibility for the site changes.
Use this short action list for the next review:
- Verify that uptime checks cover the homepage and the site’s most important user journey.
- Confirm that alerts reach more than one responsible person and include useful timestamps and URLs.
- Test DNS resolution, HTTPS, redirects, forms, and key application paths.
- Confirm that backups are completing and that a restoration has been tested, not merely assumed.
- Refresh hosting support channels, escalation details, account access, and current uptime terms.
- Record the top recurring failure pattern and assign one preventive improvement.
Keep the completed incident notes with deployment and infrastructure records. Over time, this creates a practical reliability history: not just how often the website went down, but how quickly the team detected the problem, identified the failing layer, restored service, and prevented a repeat.
