
Short answer: Here’s what to do when your website is down: first confirm it’s down for everyone, not just your computer. Then read the exact error to work out which layer failed: the domain, DNS, the security certificate, the hosting server, the website software, or an attacker. Contact the party who controls that layer, tell customers briefly, and only restore a backup once you know the cause and know a restore will fix it. Most outages are fixed without touching a backup, and in a hack, restoring too early can destroy evidence and put the attacker’s backdoor straight back.
This guide covers the first hour, before the restore decision. If you’ve already confirmed that you need to roll back, go straight to the step-by-step restore procedure in our website backup strategy guide. That guide also covers how to set up backups and test them, which this article doesn’t repeat.
A backup replaces your site’s files and database with an older copy. That only helps when the files or database are the problem. Many of the most common outages sit somewhere else:
Even when the site’s files are the problem, a restore has a cost. It rolls back every order, booking, form entry and post since the backup was taken. In a compromise, it overwrites the evidence of how the attacker got in, and if the backup was taken after the break-in, it restores the attacker’s access too.
So the first hour is about diagnosis. 4GoodHosting’s article on what actually takes WordPress sites down makes the same point from the hosting side: software, configuration and administrative problems such as expired certificates and domains cause far more outages than hardware failure does.
The timings below are a guide to order, not a target. Some outages are solved in five minutes, and some need a host or developer for longer.
| Time | Goal | What you do |
|---|---|---|
| Minutes 0-5 | Confirm the outage | Check from a phone on mobile data and a private browser window. Ask someone elsewhere to try. |
| Minutes 5-15 | Find the failed layer | Write down the exact error, check whether email is also down, and match the symptom to the table below. |
| Minutes 15-30 | Contain and communicate | If there are signs of a hack, take the site offline and change passwords from a clean device. Post a short notice to customers. |
| Minutes 30-60 | Fix, escalate or decide to restore | Fix it yourself if it’s in your control. Otherwise open a ticket or call with the evidence. Decide whether a restore is actually needed. |
| After the hour | Verify and record | Test from outside your network, check forms and checkout, and write down what happened and when. |
Check from somewhere that doesn’t share your connection, your browser or your saved passwords. A site that loads on your phone over mobile data but not on your office Wi-Fi is usually a local or network problem, not a site problem.
Run these quick checks, in this order:
If the site fails only from your office, your IP address may be blocked. Hosting firewalls commonly block an address after repeated failed logins. 4GoodHosting’s guide to whitelisting your IP explains this for its Linux hosting servers. The firewall automatically blocks IP addresses after repeated failed logins to cPanel, FTP, email or webmail, and Standard Linux Web Hosting customers can unban their own address from the billing portal. The same guide warns that a device or mail client still trying an old password will block the address again. That’s a common cause of an “outage” that keeps coming back every morning.
If you recently changed DNS, your computer or your internet provider may still have the old answer cached. Google Public DNS has a Flush Cache tool for clearing its own cached copy of a domain. Other DNS providers clear their caches on their own schedule.
The exact wording on the screen tells you more than “the site is down” does. Take a screenshot, note the time, and check one more thing: does email on the same domain still work? If both the website and email stopped at the same time, the problem is almost certainly the domain or DNS, because those are the only layers they share.
| What you see | Most likely layer | First check | Who can fix it |
|---|---|---|---|
| “This site can’t be reached” or “server IP address could not be found” | Domain or DNS | Domain expiry date and nameservers | You, via the registrar or DNS host |
| A registrar’s page saying the domain has expired | Domain registration | Renew it with the registrar | You, via the registrar |
| A full-page “Your connection is not private” warning | TLS certificate | Certificate expiry date and the hostnames it covers | You or your host |
| “Briefly unavailable for scheduled maintenance” | A WordPress update that didn’t finish | A leftover .maintenance file in the site root | You |
| “There has been a critical error on this website”, or a blank white page | PHP fatal error, usually a plugin or theme | The WordPress recovery mode email, then the error log | You or your developer |
| “Error establishing a database connection” | Database settings or database server | Database details in wp-config.php | You, or your host if the server is down |
| 500 Internal Server Error | Website code or server configuration | The error log, then the .htaccess file | You or your host |
| 502, 503 or 504 errors | Server, overload or proxy | Your host’s status updates and your account’s resource use | Usually your host |
| A Cloudflare-branded 521 or 522 error | The origin server behind Cloudflare | Whether the hosting server is up and accepting Cloudflare’s connections | Usually your host |
| An “account suspended” page | Billing or an abuse report | Your billing account and any emails from the host | You and your host |
| The site loads but redirects to spam, or Google or Chrome shows a security warning | Compromise | See the hacked-site section below | You, your host and possibly a security specialist |
The sections below cover the checks for each layer. Work through only the one that matches your symptom.
An expired domain is one of the most preventable total outages. The rules depend on the extension:
If the domain has lapsed, renew it with the registrar first. Then check the nameservers haven’t been changed to the registrar’s parking servers, and allow time for DNS to update. 4GoodHosting’s domain pointing guide says DNS changes usually take a few hours, and up to about 24 hours worldwide. Search for the renewal reminders in every inbox you own, including spam. Reminders that went to an old address or a former employee are a common root cause. Our guide to choosing a domain extension covers auto-renew and why a lapsed name can be lost for good.
If the domain is current, the next suspect is a DNS change. Ask who last edited the nameservers or DNS records, and when. A site that works for some visitors and not others, or works on one network but not another, often points to a DNS change that hasn’t reached everyone yet.
An expired TLS certificate (often still called an SSL certificate) blocks visitors with a full-page warning, even though the site behind it is working. Certificates now expire more often than they used to. Under the CA/Browser Forum’s Baseline Requirements, certificates issued on or after March 15, 2026 can be valid for at most 200 days. The maximum drops to 100 days on March 15, 2027 and 47 days on March 15, 2029. A manual renewal process that worked once a year will not keep up, so this kind of outage is likely to become more common on sites that don’t renew automatically.
4GoodHosting’s SSL and HTTPS troubleshooting guide lists the common symptoms:
The guide asks customers who are still stuck to open a ticket with the domain name and a screenshot of cPanel’s SSL/TLS Status page.
These errors come from the website software, so they’re usually in your control, and they usually follow a change: a plugin, theme or core update, a PHP version change, or an edit to theme code. Ask what changed in the last 24 hours before you touch anything.
If the error started right after you changed the PHP version, switching back is a quick test. Once the site is back, test plugin and theme updates on a staging copy before they reach the live site. Our guide to WordPress hosting, security and backups explains why updates are the biggest risk, and why turning them off isn’t the answer.
Status codes in the 500s mean the server side failed, but they point to different places. MDN’s references describe them like this:
If your site sits behind Cloudflare, its error pages say which side failed. Cloudflare’s documentation says error 521 means the origin web server refused Cloudflare’s connections, and error 522 means Cloudflare timed out contacting it. Either way, the problem is usually at the hosting server, not at Cloudflare.
When the host needs to act, a good first message saves a round of questions. Include:
4GoodHosting’s contact page lists 24/7 phone support at 1 866 708 4678, as well as live chat. Whoever your host is, find their support and status channels now and keep them somewhere other than your website and your work email, because both may be down when you need them.
Treat it as a possible hack if you see any of these:
Google’s help page on sites labelled as dangerous explains how to check:
Be careful how you look. web.dev’s guide to sites hacked with malware advises against viewing infected pages in a normal browser, because malware often spreads through browser vulnerabilities. It suggests using a tool such as cURL instead. Setting a Google referrer or a phone user agent helps, because hacked sites often show the malicious content only to visitors who arrive from search or on mobile, and hide it from the owner.
In the first half hour, focus on containment, not cleanup:
A short, honest notice beats silence, and it beats a confident guess about the cause. If email on your domain is down too, use channels that don’t depend on the domain: social media, your phone greeting, or a personal email to customers with orders or appointments that are due.
The wording below is an example to adapt, not a template you must use:
Keep three rules in mind:
By now you should know which layer failed. The table below shows when a backup is actually the answer.
| Cause | The right fix | Is a restore needed? |
|---|---|---|
| Expired domain | Renew with the registrar, then check the nameservers | No |
| DNS change | Correct the records, then wait for the change to spread | No |
| Expired or mismatched certificate | Renew or reissue it for every hostname, including www | No |
| Your IP blocked by the host’s firewall | Unban the IP address and update old saved passwords | No |
| Host outage or overload | The host fixes it. You keep evidence and check whether you’re on the right plan | No |
| Faulty plugin, theme or update | Deactivate it or roll it back, then test the fix on staging | Usually not |
| Leftover .maintenance or a broken .htaccess file | Delete or rename the file | No |
| Content or files deleted by mistake | Restore only the affected files or database tables | Partial restore |
| Database corrupted | Ask the host to repair it, then restore if a repair fails | Sometimes |
| Hacked site | Contain, preserve a copy, find the entry point, then clean or restore | Often, but only after the earlier steps |
If a restore is needed, follow the order in our website backup strategy guide: choose a restore point from before the problem, restore files and then the database, close the hole, verify the site, and then reconcile any orders or entries the restore rolled back.
Once the site loads again, don’t trust your own browser. Check from mobile data, test the contact form and checkout, and confirm that email sends and arrives. If there was a hack and Google flagged the site, request a review in Search Console’s Security Issues report once the whole site is clean.
Then write a short timeline while you still remember it: when the outage started, when you noticed it, the cause, what fixed it and how long each step took. Two notes are worth adding:
If your site is hosted with 4GoodHosting, several first-hour checks have self-service tools or published guides. They include the IP Unban Center for Standard Linux Web Hosting customers, the SSL and HTTPS troubleshooting checklist, the nameserver guide and the password reset guide. The company lists 24/7 phone support and live chat on its contact page. Its uptime article is a good next read for setting up monitoring and a runbook before the next outage.
Load the site on a phone using mobile data with Wi-Fi turned off, then in a private browser window, and ask someone in another location to try. If it works everywhere except your office, the likely causes are a firewall block on your IP address, cached DNS or a local network problem, not the website itself.
The website and email on the same domain share the domain registration and DNS, so both failing together usually points to an expired domain or a DNS change. Check your registrar account for the renewal status, then check that the nameservers and records haven’t changed.
Not straight away. First take the site offline, change passwords from a clean device and copy the hacked files and database. A restore point taken after the break-in brings the attacker’s access back, and restoring over the hacked copy destroys the evidence of how they got in. Restore only once you know a clean restore point and how the attacker got in.
It depends on how long the DNS records were cached. 4GoodHosting’s guide says nameserver changes usually take a few hours, and up to about 24 hours worldwide. During that time, some visitors may reach the new setup and others the old one.
A short outage is not usually a lasting problem. Google’s guidance on temporarily pausing a site says to use a 503 status code for an urgent shutdown of a day or two. It warns that disabling a whole site for longer than a few days can significantly affect how the site appears in Search. Fix the outage, then check Search Console for crawl errors.
Contact whoever controls the layer that failed. That’s the registrar for an expired domain, whoever manages DNS for a record change, the host for 5xx errors, server outages and account suspensions, and your developer for plugin, theme or code errors. The symptom table above maps each error to the right contact.
About the author: This article was written by the team at 4GoodHosting, a Canadian web hosting company operating since 2002 with servers in Vancouver and Toronto.





