The First 30 Minutes of a Website Outage: An Incident Playbook

When your website is unavailable, your first reaction may be to disable a plugin, change a DNS record or restart the server. If the action targets the wrong layer, it can extend the outage. Start by determining whether all visitors are affected, only certain networks are affected, or only one page is failing.

A useful website outage response plan gives the first 30 minutes a clear order: measure the impact, collect evidence, apply the narrowest safe change and verify that access has returned. The process below applies to WordPress and WooCommerce sites as well as custom PHP applications.

Minutes 0-5: Determine the outage scope

First establish whether the site is broadly unavailable or whether the problem is limited to one device or network. A page failing on your own computer does not prove that the server is down. Local DNS cache, a corporate firewall, browser cache or your internet service provider may also be involved.

Run quick tests from different clients

Check the same domain from a phone using mobile data and, if possible, a computer on another connection. Test the homepage, the administration panel, a static file and a known product page. This helps you see whether the problem affects the entire site or a particular application route.

Write down the browser error exactly. DNS_PROBE_FINISHED_NXDOMAIN, ERR_CONNECTION_REFUSED, a TLS certificate warning, 403, 404, 502, 503 and 504 do not identify the same failure. Record the code, time and tested address in an incident note instead of relying only on a screenshot.

curl -I --max-time 15 https://your-domain.example/

This command sends a header request to the HTTPS address. curl must be installed on your computer or server; you do not need to log in to the site. An HTTP response such as 200 or 301 shows that you reached the web server, but it does not prove that the application is healthy. Some applications handle HEAD requests differently, so compare the result with a GET test that also retrieves the response body when necessary. A 502 or 504 can indicate a communication problem between the web server and its backend, while a 503 suggests that the service is temporarily unavailable.

If the browser and command line produce different results, a proxy, CDN, DNS cache or device-specific condition may be involved. Do not change DNS or SSL settings based on one test.

Build a timeline of recent changes

List changes made shortly before the outage: a DNS update, domain renewal, SSL renewal, plugin or theme update, server configuration change, PHP version change, database maintenance or traffic increase. Timing does not prove causation, but it helps you decide which checks to perform first.

The goal at this stage is not to fix everything. Record the scope, start time, test network, error code and recent changes in the incident log.

Minutes 5-10: Separate DNS from domain routing

DNS maps a domain to an IP address or another destination. With a DNS failure, the browser may never reach the web server. DNS checks and web-server checks therefore need to remain separate.

Check the expected DNS records

The following queries show the A, AAAA and CNAME records returned by your configured resolver. They are useful for comparing client-visible results; they are not, by themselves, an authoritative DNS check. Check AAAA as well as A if you use IPv6.

dig +short A your-domain.example
dig +short AAAA your-domain.example
dig +short CNAME www.your-domain.example

dig is common on Linux and macOS. On Windows, use your DNS management panel or an installed DNS tool for equivalent queries. An empty response, an incorrect destination, an unexpected CNAME or an IPv6-only record can cause access problems. DNS caches can also make different clients show different results for a period of time.

Confirm the record at the authoritative DNS provider as well as the result returned by a client resolver. If the A record does not show the current server IP, find the source of the discrepancy: a recent change, domain management account, DNS template or automated deployment system. Save the current DNS zone or record values before editing anything so you can restore them if needed, and change only the record that is demonstrably wrong. Do not enter a random new IP.

For a broader review of DNS and delivery dependencies, a guide to CDN caching can help you distinguish cached responses from origin-server responses. CDN cache behavior can affect what some visitors see, but it does not by itself prove that the origin server is unavailable.

If DNS points to the expected destination but the site still fails, move to the next layer. Repeatedly changing DNS will not solve a web-server or application problem and may create more inconsistent cached responses.

Minutes 10-15: Test SSL and the web server

If DNS reaches the expected destination and a connection can be established, assess the SSL/TLS handshake and the web-server response separately. SSL/TLS encrypts the connection between browser and server and validates the certificate.

Check the certificate and its validity

If the browser shows a certificate warning, check whether the certificate covers the domain, whether its validity dates are current and whether the intermediate certificates are being served. If OpenSSL is installed, this command provides a basic observation:

openssl s_client -connect your-domain.example:443 -servername your-domain.example < /dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

The command displays the certificate’s start and end dates, subject and certificate authority. Use the output for diagnosis, not as an instruction to apply a change. If the certificate has expired, check the logs and prerequisites of the certificate management tool you use. Back up the current configuration and define a rollback file before changing certificate files manually. After renewal, repeat the certificate check and an HTTPS request from an independent network.

A separate reference on SSL certificate checks can help when the certificate covers the wrong hostname or the renewal process has failed.

Check HTTP responses and virtual-host matching

If the TLS test succeeds but the browser shows 502, 503 or 504, the request reached the web server but the backend may be failing. Search the access and error logs for Nginx, Apache, LiteSpeed or your web server during the outage window. Log paths vary by operating system and control panel; do not delete an unfamiliar file or manually trigger log rotation.

An unexpected 404 or content from another site can indicate a virtual-host mismatch, incorrect document root or faulty redirect rules. Inspect only the configuration for the affected domain. Rebuilding the entire web-server configuration could affect other sites that are working.

If you changed web-server configuration, validate its syntax before reloading the service. Commands vary by software and operating system, so use the documented test and rollback method for your service manager. Repeat the same curl -I test after the reload and compare the response with the result recorded before the change.

Minutes 15-22: Separate the app, database and PHP layers

If the web server responds but WordPress, WooCommerce or a custom application fails, inspect the application layer. A blank page, 500 error, slow administration panel and unavailable product pages are different symptoms. Disabling plugins, changing PHP versions and repairing the database at the same time makes it impossible to identify which action helped.

Review application logs by time range

Compare the web-server error log with the PHP error log for the same minutes. Allowed memory size, maximum execution time, connection refusal, missing files and database authentication errors require different responses. If you use WordPress, do not leave unrestricted debug logging enabled in production; logs may contain personal data or connection details.

If a database connection fails, check that the database service is running and that the username, password, database name and host in the application configuration have not changed. Take a secure copy of the configuration file first. Never place the password in logs or send database credentials in plain text through a support request.

Repairing tables, deleting data, running bulk updates or restoring a database changes data. Do not perform those actions without a current backup and a rollback plan. If the problem began immediately after one plugin or theme update, use the platform’s safe deactivation method and an existing file backup to isolate only that component. Verify the affected page and review the logs after each isolation step.

Do not confuse PHP-FPM with CLI work

PHP-FPM workers handle web requests. CLI cron jobs, queue consumers and import commands do not consume a PHP-FPM worker unless they make an HTTP request, but they can compete for the same CPU, RAM, disk and database resources. This distinction matters when testing the assumption that the web-worker pool is full.

If all PHP-FPM workers are occupied, logs may show waiting requests, timeouts or child-process limit symptoms. If a CLI queue consumes excessive CPU or database connections, web requests may still slow down. Measure which process is using resources before temporarily reducing that job’s speed or concurrency. Increasing worker counts blindly can increase RAM consumption.

Minutes 22-27: Check resource limits and traffic

If the site works intermittently or times out, a resource limit or sudden traffic increase becomes more plausible. Consider CPU, RAM, PHP processes, disk space, disk I/O and database connection counts together. On shared hosting, some of these metrics may be available in the control panel; on a VPS or dedicated server, they may be available through operating-system and service monitoring tools.

Check the control panel for process limits, CPU graphs, RAM limits, inode counts, disk usage, I/O limits and concurrent-connection warnings. Exceeding a limit does not automatically mean that you should raise it. First identify which URL, cron job, plugin, import or traffic source created the load.

If you have VPS access, these read-only commands provide a general snapshot:

uptime
free -h
df -h
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head

These commands require a Unix-like shell and standard system utilities; output and available columns can vary by operating system. They show load average, memory, disk usage and processes using CPU at that moment. If df -h shows a completely full filesystem, logs may stop writing and database operations may fail. Identify which files are safe before deleting anything; log, upload and backup directories can contain data that you still need. Repeat the snapshot after a targeted change to see whether the suspected pressure has changed.

On WooCommerce sites, treat aggressive cache clearing and queue stopping carefully when payments, stock or orders are involved. Restarting an application or restoring a database while orders are being written can lose new records. First document the transaction activity and the time of the errors.

For planning resource needs, the guide to CPU, RAM and bandwidth can provide useful context. General capacity calculations do not prove the cause of the current outage.

Minutes 27-30: Check the provider and verify the result

If DNS, SSL, the web server and the application do not explain the failure, check your provider’s status page, maintenance notices and support channel. On shared hosting, a node, network, storage or control-panel problem may not be visible within your account. With a VPS, a running virtual server does not rule out a data-center network or underlying storage problem.

Include the domain, outage start time, results from different networks, HTTP code, DNS result and safe checks already completed in your support request. Do not send passwords, private keys, database credentials or personal customer data. If the provider asks you to restart the server, ask how that may affect data, open orders or running imports.

After changing a setting, verify one change at a time. Test the homepage, administration panel, a critical product or contact form and, if possible, access from a new session. Repeat the HTTP request and check the logs for new errors. If the problem remains, revert the change; a sequence of untracked changes makes rollback harder.

Improve the process after the first 30 minutes

After the site returns, separate the root cause from the conditions that increased the risk. An expired certificate may be the root cause, while the absence of a renewal alert is a contributing condition. A resource limit may explain the outage, but you should still investigate which cron job triggered it.

Keep the timeline, relevant log excerpts, changed settings, verification results and rollback action. During planned maintenance, test whether backups of application files, the database and server configuration can actually be restored. If you use monitoring, alert on critical transactions and access from different networks, not only on the homepage.

A guide to uptime monitoring and alerting can help you plan earlier detection. Enabling a monitoring endpoint is not enough; you also need to define a secure web-server access path to it. Do not expose an endpoint that returns management information to everyone. Protect it with authentication, IP restrictions or a limited response.

Frequently Asked Questions

What does it mean if only some visitors cannot open the site?

Different DNS responses, IPv4 and IPv6 paths, CDN caches or regional network problems are possible. Compare mobile data with a fixed connection and compare A and AAAA results. If one resolver is affected, provide the provider with the relevant query times.

Should you restart the server immediately?

A restart may clear a temporary lockup, but it can remove useful process evidence and interrupt active work. Record the error time, resource usage and critical data operations first. Unless the provider recommends it and you understand the impact, do not make it the first option.

Does a 503 always come from the hosting provider?

No. A PHP-FPM pool, application maintenance mode, resource limit, traffic spike or web-server configuration can also produce a 503. Match the response with web-server and application logs for the same time period, and check whether the response comes from a fixed maintenance page or the application.

How can you verify that a DNS change has propagated?

Query from different networks and DNS resolvers, but do not treat one query as proof of complete propagation. TTL and cache behavior determine how long old and new responses remain visible. Compare the record at the authoritative DNS server with the response received by clients.

Actionable checklist

• Record the outage start time, affected URLs, networks and error codes.
• Compare access over mobile data and another connection.
• Compare A, AAAA and, where relevant, CNAME records with the expected destinations.
• Verify the SSL certificate’s hostname and validity dates.
• Review HTTP headers, web-server logs and PHP application logs for the same time window.
• Test the database connection and application error without changing data.
• Evaluate PHP-FPM web workers separately from CLI cron and queue processes.
• Check CPU, RAM, disk, I/O, PHP processes and database connection limits.
• Review provider notices and the support channel.
• Apply one narrow change, retest access and revert it if it does not help.

Turn this list into an accessible incident document with your control-panel details, support information, DNS records and rollback procedures. During the next maintenance window, test monitoring for the homepage, administration panel and critical transaction flows.