When a WordPress site is down, first determine whether the failure is DNS, HTTPS, hosting, or the application. Preserve the original error and recent-change timeline before restoring anything. A full database restore can erase orders and leads created after the backup.
The time blocks below are a suggested incident structure, not a promise that every outage can be repaired in 30 minutes. Escalate immediately when payments, customer data, or signs of compromise are involved.
Minutes 0 to 5: Confirm the Scope
Open the public homepage and one important inner page from a second connection or monitoring location. Record the exact error and UTC time. If only one employee cannot connect, compare their network and DNS before changing the website for everybody.
Check whether wp-admin, a static image, and the primary form or checkout share the failure. Pause unrelated deployments. Name one incident lead so two people do not simultaneously change plugins, DNS, and cache rules.
Minutes 5 to 10: Classify the Response
Run a public request without credentials, replacing the example domain:
curl -sS -I --max-time 15 'https://example.com/'
No DNS resolution, a certificate error, a redirect loop, a 5xx response, and a normal HTTP response containing an error page require different investigations. A 200 status alone does not mean WordPress is serving useful content.
Check your host's status and incident notices through a known official channel. Never use contact details supplied by an unexpected error-page popup. If the provider reports an active infrastructure outage, give support your affected hostname and timestamp rather than changing site content speculatively.
Explanatory evidence sheet. Record your own observations.
Minutes 10 to 20: Find the First Change or Error
Review deployment records, plugin updates, hosting changes, and relevant server logs around the first failure. Read the initial fatal error, not just repeated downstream errors. Preserve a private copy before clearing logs or caches.
For a clear update-related failure, use the plugin rollback guide. For a site left in maintenance during a failed upgrade, WordPress update documentation describes the maintenance-file recovery step. First confirm an update is not still running; removing its marker does not repair incomplete files.
Do not disable every security layer, recursively loosen permissions, or delete unfamiliar files as a generic recovery method. Suspected compromise needs containment and evidence preservation, not a rushed cleanup based on filenames alone.
Minutes 20 to 30: Prove Recovery or Escalate
After a targeted correction, test the same failing URL and the actual business path. A working homepage does not prove that checkout, sign-in, or email recovered. Confirm database writes and external payment state with authorized test procedures.
If restoration is necessary, agree on the recovery point and how newer orders or submissions will be reconciled. The backup recovery guide explains why a green backup job is not sufficient evidence.
Send support a concise packet: affected URLs, start time, scope, exact status or error, recent changes, attempted actions, and current business impact. Redact secrets. HandL WP's one-time fix service is a path for a defined WordPress fault; hosting-wide incidents still need the hosting provider involved.
Sources checked September 27, 2026. Examples and diagrams are explanatory, not customer measurements.