# WordPress Site Down? A Calm 15-Minute Checklist · WPCloudLab > WordPress site down? A calm 15-minute checklist: confirm the outage, read the error, find the last change, and know when to restore or call your host. Canonical: https://wpcloudlab.com/guides/wordpress-site-down [Home](/)/[Guides](/guides)/Site down guide · outage triage · read calmly, act in order # Your WordPress site is down. Breathe. This is the checklist we run when a rescue call comes in. Most outages trace to one of six causes, and the order you check them in matters more than speed. Work the list top to bottom — about fifteen minutes, no thrashing. [or skip straight to a rescue →](/contact) 001 / the triagesix steps · in order step 01 · two minutes ## Confirm it’s actually down. Before anything else: down, or down _for you_? Put the URL into downforeveryoneorjustme.com or any “is it up” checker. Then try it from your phone on mobile data — not your wifi — and in a private browser window. If it loads for the checker, the problem is on your side: local DNS, the office network, a VPN, a stale cache. Annoying, but invisible to your visitors — the emergency just became a nuisance. If the checker agrees it’s down, keep going. step 02 · three minutes ## Check the boring externals. The most embarrassing outages have nothing to do with WordPress. Three quick lookups before touching any code: - 01 Domain expiry. Run a whois lookup on your domain. An expired domain is the most total outage there is, and the renewal warnings went to an inbox nobody reads. - 02 SSL certificate. If browsers show a security warning instead of an error page, your certificate has expired. Most hosting panels reissue one in minutes. - 03 Hosting status page and DNS. Check your host’s status page — if they’re having an incident, that’s your answer; skip to step six. And if anyone touched DNS in the last 48 hours, that change is your prime suspect. step 03 · two minutes ## Read the error like a map. Whatever the browser shows you narrows the search enormously. Match the symptom: what you see usually means first move White screen, nothing at all Fatal PHP error — usually a plugin or the theme Check email for the WordPress recovery link, then step 4 500 Internal Server Error Server-side error — often a plugin or a broken .htaccess Step 4; renaming .htaccess over SFTP is a fair second test 502 / 503 / 504 The server behind the site is overloaded or down Usually the host's side — status page, then step 6 Error establishing a database connection Database credentials wrong or the database server is down If you changed nothing, it's the host's — step 6 Browser security warning Expired or misconfigured SSL certificate Reissue from the hosting panel (step 2) One shortcut worth knowing: since WordPress 5.2, many fatal errors email the site’s admin address a recovery-mode link. Search your inbox for “Your Site is Experiencing a Technical Issue” — that email names the exact plugin or theme at fault, which is the fastest diagnosis you will get today. step 04 · five minutes ## Ask the only question that matters: what changed? Sites rarely fall over spontaneously. Did a plugin auto-update overnight? Did someone install something yesterday? Edit the theme? In our rescue work, the last change is the culprit in most self-inflicted outages — and updates are the most common last change. If wp-admin is unreachable, you can still disable the suspect without touching the database, using the rename trick. Carefully: - 01 Connect to your server with SFTP or your host’s file manager and open wp-content/plugins/. - 02 Rename the suspect plugin’s folder — say, from woo-addon to woo-addon.off. Renaming the folder deactivates that one plugin. Nothing is deleted; nothing touches the database. - 03 Reload the site. If it comes back, you have your culprit: leave it off, and either roll it back to the previous version or contact its developer. - 04 No obvious suspect? Rename the whole plugins folder to plugins.off. If the site returns, rename it back — WordPress will have deactivated everything — then reactivate plugins one at a time in wp-admin until the site breaks again. The last one you touched is the offender. - 05 Theme suspected? The same rename trick in wp-content/themes forces WordPress to fall back to a default theme, if one is installed. step 05 · the judgment call ## Restore from backup — if you trust it. If nothing above worked, or the site is visibly damaged — defaced, malware warnings, database errors that survive a host reboot — restoring the most recent clean backup is usually the fastest route back. One click on managed setups; a files-plus-database import elsewhere. Two catches. First, everything since that backup — orders, form entries, edits — disappears unless you deliberately merge it back; know what you’re giving up before you click. Second, the big one: a restore is only as good as the backup behind it, and mid-outage is the worst possible moment to discover yours has been quietly broken for months. Whether you can trust a backup you’ve never tested is the entire subject of our [backup strategy guide](/guides/wordpress-backup-strategy). Read it on a calmer day than this one. step 06 · escalation ## Your problem, or the host’s? Call the host when the evidence points below your site: their status page shows an incident, the error is a 502/503/504, the database server is unreachable and you changed nothing, or SFTP itself won’t connect. Open the ticket with what you’ve ruled out — “not the domain, not the SSL, all plugins disabled” — and you skip the first forty minutes of script. It’s on you (or whoever maintains the site) when the timeline says update, install or edit. The host will confirm the server is healthy, and they’ll be right. That’s not a dead end — it’s a diagnosis: back to step four, or hand it to someone who does this every day. after the fire ## Make the next one quieter. Two habits turn outages from crises into blips. First, monitoring that tells you before a customer does: [one-minute uptime checks](/features/uptime) mean you hear about a 4am outage at 4:01, not in a 9am email — our Extended plan checks every minute with instant alerts, and every plan at least every five. Second, remove the most common cause: [updates with a restore point, before/after screenshots and automatic rollback](/features/safe-updates) catch the regression before it becomes the outage. Between those two habits sits most of the difference between sites that go down monthly and sites that don’t. 002 / questionsasked mid-outage ## Outage questions, answered. How long does it take to recover a down WordPress site? Most self-inflicted outages — a bad update, a plugin conflict — resolve in 15–60 minutes once you work the steps in order. A restore from a good backup typically takes minutes to an hour depending on site size. Hosting incidents last as long as they last; your job is confirming it's theirs and getting a ticket in early. Hacked sites are the long tail: proper cleanup can take days, which is why prevention is the cheap option. Will restoring from a backup lose my recent data? Anything created after the backup was taken — orders, form submissions, edits — is not in the restore. Restoring from last night loses hours; from last week, a week. On commerce sites, export recent orders first if the database is still reachable, and merge them back after. This is also why backup frequency and retention are worth deciding before the bad day. My site goes down every month. How do I stop it? Recurring outages are almost always one of three things: a hosting plan too small for the traffic, one repeat-offender plugin (read your last three incidents together — the same name usually appears), or unreviewed automatic updates. Fix the pattern, not the incident. If it's updates, run them with a restore point and a visual check instead of blind — that single change removes the most common cause. belov.cloud · hosting by the same family ## Tired of reading this guide? Get hosting that heals itself. belov.cloud is managed WordPress and Node/Next.js hosting built by the founders of Belov Digital — with an always-on AI copilot that detects, diagnoses and fixes incidents in under a minute. Pair it with your care plan and one family of engineers answers for the whole stack: hosting heals the platform, webcare runs updates, backups and reports. - Self-healing: detect → fixed in under 60s, every remedy reversible - Free migration off any host — WP Engine, Kinsta, GoDaddy, anywhere - Flat price — traffic spikes don't spike the invoice [Explore belov.cloud](https://belov.cloud/?utm_source=wpcloudlab&utm_medium=referral&utm_campaign=crosssell&utm_content=guide-site-down) 60-day money-back · runs WordPress and Next.js side by side site down right now? · we do rescues ## Want a human on this now? Send the URL and what you’ve already tried — the six steps above save us both time. A WordPress engineer picks it up, usually inside the hour. And if you’d rather never read this page again, that’s exactly what the maintenance plans are for. [Get emergency help](/contact)[see plans & pricing →](/pricing) --- Get started: https://wpcloudlab.com/signup · Talk to an engineer: https://wpcloudlab.com/contact · Full agent index: https://wpcloudlab.com/llms.txt