Your website is not loading, or someone has just told you it is not. The pressure to fix it is high, and it is easy to waste the first twenty minutes guessing. This checklist puts the checks in a sensible order, from the quickest and most common causes to the rarer ones, so you find the problem faster.
Work through it from the top. Most outages are found in the first four steps.
1. Confirm it is really down, and for whom
Before changing anything, find out what is actually happening.
- Load the site on your phone using mobile data instead of your usual network. This rules out a problem with your own connection or office network.
- Open it in a private window, in case a cached copy or a stale login is hiding the problem or causing it.
- Ask someone elsewhere to try, or check a monitoring service. Your monitor’s history shows when the problem began, whether it is every region or one, and whether it is constant or intermittent.
- Check whether it is the whole site or one page. A broken checkout with a working homepage points at your application, not your server.
Note the exact time it started. Everything that happened just before it, a deployment, a plugin update, a configuration change, is a suspect.
2. Read the error
What the browser shows narrows the search a great deal.
| What you see | What it usually means |
|---|---|
| “This site can’t be reached”, or a DNS error | The domain isn’t resolving: a DNS problem or an expired domain. |
| A connection timed out or refused | The server is off, overloaded, or a firewall is blocking it. |
| A security warning about the certificate | The SSL certificate has expired or is misconfigured. |
| 500 Internal Server Error | The server answered, but your application failed. |
| 502 Bad Gateway or 504 Gateway Timeout | A proxy or load balancer can’t get an answer from the application behind it. |
| 503 Service Unavailable | The server is overloaded, restarting or in maintenance mode. |
| 404 on pages that used to work | A routing, rewrite or deployment problem. |
| A blank white page | A fatal error in the application with error display switched off. |
3. Check the domain and DNS
If the browser cannot find the site at all, start here. Check that the domain has not expired: a missed renewal is a surprisingly common cause, and the registrar will usually have emailed warnings you did not see. Then check that the DNS records still point at your server. A recent change to nameservers or records, even a correct one, can take hours to reach everybody, and can look like an outage from some places and not others.
4. Check the SSL certificate
If the page opens with a warning that the connection is not private, the certificate has probably expired, was not renewed, or does not match the domain. Browsers block these pages, so to visitors the site is as good as down. See how to prevent an expired SSL certificate for the fix and how to stop it happening again.
5. Check the server and hosting
- Hosting status. Look at your provider’s status page and your email for notices. A wider outage means the work is waiting, not fixing.
- Is the server running? Look in the hosting control panel. A server that has run out of memory or been rebooted may not have restarted the web service.
- Disk space. A full disk stops databases writing, logs rotating and sessions saving, and produces confusing errors. It is a very common cause of sudden failure.
- Memory and load. A traffic spike, a bot hammering the site or a runaway process can use up everything the server has.
- Web server and PHP processes. Check that the web server and any application process, such as PHP-FPM, are running, and restart them if they are not.
6. Check the database
If the server is up but the site shows an error, check that the database is reachable. Common causes are a stopped database service, too many connections, a full disk, a changed password and a database host that has moved. “Error establishing a database connection” and similar messages point straight here.
7. Check what changed
If the cause is not obvious, ask what changed in the hour before the problem began.
- A deployment: roll it back first and investigate afterwards, if you can.
- A plugin, theme or dependency update.
- A configuration or environment change, such as a changed key or an expired credential.
- A scheduled job that has gone wrong, such as one that fills a disk or locks a table. A heartbeat check on those jobs would have flagged it earlier.
The application’s own error log, usually the web server’s error log or the framework’s log file, will often name the problem in one line.
8. Check third parties
A site can fail because something it depends on has. A CDN, a payment provider, an authentication service or an API that loads on every page can each make a healthy server appear broken. Check their status pages, and see whether the site works with the failing part switched off.
9. Tell people, then keep a record
While you work, say something. A short message on social media, a status note or an email to key customers costs little and saves a lot of trust. Afterwards, write down what happened, when it started, when it ended and what fixed it. The record is what stops the same outage happening twice.
Next time, know first
The longest part of most outages is the time before anyone notices. A monitor requests your site every few minutes and alerts you the moment it fails, so you are already working through this list when the first customer would have emailed. Why you need to monitor your website explains what a delay costs, and website monitoring shows how Pingvella does it, with five website checks on every account, free.
Common questions
Can Pingvella tell me if my website is down?
Yes. Add a website check with the address of your site or health page and Pingvella requests it every 5 minutes on the free plan, every 2 minutes on Business and every minute on Professional. A non-2xx response, a timeout or a connection or certificate error marks it down and sends your alerts, with a recovery notice when it is back. Every account can have five website checks. For sites that are not reachable from the internet, run the request from your own scheduler and check in only when it succeeds.
What counts as my website being down?
Anything other than a successful 2xx response once redirects are followed: an error page, a timeout, a refused or dropped connection, an expired or invalid SSL certificate, or an address that no longer resolves.
Where can alerts be sent?
Email, Slack, Discord, Microsoft Teams, Telegram or any custom webhook. You are alerted when a check goes down and again when it recovers, and the dashboard also raises an on-screen alert while you have it open.
There are more answers on the FAQ page.