First, confirm what “down” actually means
When a WordPress site keeps going down, the visible failure rarely names the responsible layer. The homepage may fail for everyone, one visitor may be blocked, a cached page may look healthy while checkout is broken, or the server may recover before anyone captures evidence.
That distinction matters. Clearing every cache, disabling plugins, or restarting services can remove the evidence and make the next outage harder to diagnose. Moving hosts can also carry the same plugin, database, or scheduled-task problem to a new server.
Start by checking four surfaces once. Use a private window, a second network such as mobile data, the WordPress login or dashboard, and one business-critical path such as a form, booking page, account area, or checkout. Do not place repeated live orders or submissions just to prove the failure.
| What you see | What it suggests | Evidence to keep |
|---|---|---|
| Every page fails on two networks | Hosting, database, DNS, CDN, firewall, deployment, or site-wide PHP failure | Exact time, error text or status code, networks tested, and host status |
| The homepage works but login, forms, or checkout fail | A cached page is hiding an application, database, session, REST, or payment-path problem | Exact failing URL, logged-in state, response time, and matching PHP or gateway event |
| Only one network or visitor fails | Local DNS, browser cache, IP rule, country rule, CDN edge, or security block | Network, approximate location, browser, time, and firewall event without exposing the visitor’s private data |
| The site fails briefly and returns by itself | Resource exhaustion, scheduled work, traffic, automated attacks, a restarting service, or intermittent upstream failure | Start and recovery times, recurrence pattern, resource graph, and scheduled jobs in that window |
This four-surface check separates a total outage from a soft failure. A green homepage alone does not prove that a WordPress business site is healthy.
Build a WordPress outage fingerprint before changing anything
One screenshot is useful, but a repeatable fingerprint is better. Record the failure in the same format each time so a host or WordPress specialist can compare incidents instead of starting again from zero.
Capture these five signals:
- Scope: everyone, one network, logged-in users, or one page type.
- Surface: homepage, wp-admin, REST requests, form, checkout, payment return, or scheduled action.
- Response: error message, HTTP status, blank page, timeout, redirect, or incomplete content.
- Timing: first failure, recovery time, timezone, and whether the pattern repeats.
- Change window: updates, deployments, imports, campaigns, DNS changes, security rules, or hosting work shortly before the failure.
Avoid sharing complete logs, cookies, tokens, customer details, private IP addresses, or server paths in public support threads. A short, redacted first error around the timestamp is usually more useful than hundreds of later warnings.
Why a WordPress site keeps going down at predictable times
Recurring downtime often has a pattern even when it feels random. Match the timing before choosing a fix.
| Outage pattern | Check first | Do not assume |
|---|---|---|
| Immediately after a plugin, theme, WordPress, PHP, or code update | The changed component, the first fatal error, compatibility notes, and a tested rollback path | That every plugin must be disabled or the whole database restored |
| At the same time each day or week | Backups, scans, imports, reports, WP-Cron, real cron, and WooCommerce scheduled actions | That normal visitor traffic caused the spike |
| During campaigns or busy periods | PHP workers, CPU, memory, database load, uncached requests, bot traffic, and third-party calls | That upgrading hosting alone will fix inefficient requests |
| Only for one country, network, or IP range | DNS answers, CDN edge behavior, firewall events, rate limits, and regional upstream status | That WordPress itself is offline everywhere |
| The public page works while wp-admin or checkout times out | Dynamic requests, sessions, object cache, database queries, REST/AJAX calls, and security rules | That a cached homepage proves the server is healthy |
If the pattern follows a WordPress update, use the critical-error recovery order before changing multiple components. If the error specifically says that WordPress cannot connect to its database, follow the narrower database-connection checks instead of treating it as generic downtime.
Read the error as a direction, not a verdict
An error code narrows the investigation, but it does not identify the root cause by itself.
- 500 or a WordPress critical error: inspect the first PHP fatal around the failed request and the most recent change.
- 502 or 504: check whether PHP, the web server, a proxy, a CDN, or an upstream service stopped responding in time.
- 503: compare maintenance state, worker and resource limits, security controls, and host availability.
- 429: identify who returned the limit before loosening protection. Our WordPress 429 guide separates the origin, CDN, firewall, plugin, and external API layers.
- A timeout with no code: preserve the duration and affected path, then compare server, database, DNS, CDN, and external-call timing.
WordPress includes a Site Health screen that can expose configuration and scheduled-event problems while the dashboard is available. It is a useful clue, not a substitute for outage-time server evidence.
A safe 10-minute response order
1. Pause unrelated changes
Stop routine updates, imports, cache experiments, deployments, and bulk edits. If the site handles orders, bookings, memberships, or enquiries, record the last confirmed successful transaction before anyone restores or changes data.
2. Record one failure when your WordPress site keeps going down
Save the exact URL, local time with timezone, visible message or status code, visitor state, and networks tested. If the site has already recovered, record that too. Do not keep refreshing an expensive request.
3. Check the host when your WordPress site keeps going down
Look for a provider incident, account suspension, expired domain or certificate, resource-limit event, database restart, deployment, or firewall action. Ask the host for evidence from the exact outage window rather than a general statement that the server is online now.
4. Compare cached and dynamic paths
Open the homepage, login, and one important uncached workflow. You can also inspect response headers using the WordPress cache-header guide. Do not purge every layer until you know whether cached output is hiding a live application failure.
5. Read logs without exposing them to visitors
Use the hosting PHP or web-server log around the recorded timestamp. A specialist can enable WordPress logging according to the official WordPress debugging guidance, but public error display should remain off on a production site.
The WordPress error-log monitoring guide explains how to match the first useful error to the request instead of reacting to every warning in the file.
6. Choose the owner of the next action
Route DNS and domain failures to the registrar or DNS provider. Ask the host to investigate server-resource and database-service incidents. Contact a plugin vendor when you can reproduce a named defect on staging. Use a WordPress specialist when several layers interact, the cause remains unclear, custom code is involved, or the site needs controlled rollback and business-path testing.
When to get help if your WordPress site keeps going down
Basic checks should stop when the next action can remove data, weaken security, or interrupt business functions.
Stop and escalate when:
- checkout, payments, forms, bookings, memberships, or customer accounts are affected;
- the only restore point is older than recent orders, entries, users, or content;
- unexpected administrator accounts, files, redirects, or security events suggest compromise;
- resource use rises again after a restart without a known trigger;
- several plugins, the theme, PHP, and WordPress changed in the same window;
- the site works only while a business-critical component stays disabled.
Never restore an old database over current orders or leads. Keep the firewall active while testing a blocked visitor through a narrow temporary rule. Avoid repeatedly raising PHP limits when a loop or expensive query continues consuming the new limit. WordPress also maintains an official troubleshooting FAQ for controlled recovery steps.
What to send when your WordPress site keeps going down
A concise handoff can save more time than another round of plugin guessing. Send your host or WordPress specialist:
- the first failure and recovery times with timezone;
- the exact affected URLs and whether anonymous, logged-in, mobile-network, form, or checkout requests failed;
- the visible error, status code, and first relevant redacted log entry;
- recent WordPress, plugin, theme, PHP, DNS, CDN, firewall, and deployment changes;
- host resource graphs and scheduled tasks from the same window;
- the newest tested backup and the business data created after it;
- the paths that must work before the incident is considered resolved.
Webless uses this evidence during WordPress maintenance and support. We identify the failing layer, make the smallest justified repair or rollback, and verify anonymous pages, wp-admin, forms, checkout, scheduled tasks, caching, and monitoring before closing the incident.
Prevent recurring WordPress downtime from becoming a mystery
External uptime monitoring should check from outside the hosting account. However, a single homepage monitor can miss a soft failure when a CDN still serves cached HTML. Add a safe dynamic or business-path check that does not create orders or expose private data.
Keep update windows, automatic jobs, deployment records, host resource history, security events, and error logs on a shared timeline. Test the backup itself with the WordPress backup restore process. Then review recurring patterns each month rather than waiting for the next outage.
The practical answer is not to restart everything faster. Confirm the scope, preserve one clean failure, match its timing to infrastructure and WordPress events, and give the responsible provider evidence they can act on.
If your site keeps going down and the cause crosses hosting, caching, plugins, security, or custom code, send Webless the URL, timestamps, error, and recent-change window. We can diagnose the outage without turning the live site into a guessing exercise.