The moment you discover the site is down is the worst moment to make decisions. The instinct is to send an urgent message to support immediately, but half of those tickets get "everything works on our side", because the fault was never on the server. Checking in the right order saves hours and makes your message precise when you do need it.

Minute one: is it you or everyone?

Open the site in a private window without extensions, then from a mobile network, then from an external tool. If it works in one place and fails in another, the problem is your network, a local cache, or DNS lag. The uptime tool on this site tests HTTP and HTTPS from outside and reports the status code and response time: the uptime checker. If it says the site is up, the server is answering and you should look elsewhere before opening any ticket.

The five layers, in order

  • Domain: has it expired or been suspended? Check the expiry date and status codes, and rule out a payment problem.
  • DNS: do records point at the right server? Use the DNS checker and compare the IP with the one your host gave you.
  • Server: does it answer on port 443? If the tool says no response, the failure is before your code: a stopped service or a firewall.
  • Application: a 500 means the server is up but the code died. Read the error log first; do not edit files before you read it.
  • Database: a blank page or connection error often means the database is unreachable, as covered in the 500 error guide.

Status codes and what they mean in practice

500: internal error; the log is the judge. 502 and 504: a proxy did not get a response in time, usually an application service that stopped or is extremely slow. 503: the service is paused temporarily by the host. 522 and 524: the edge could not reach the origin, so the fault sits between edge and server. 403: the file exists but permissions deny it, common after a file permission change. SSL warning: the certificate expired or does not match the name; verification and fixes are in the SSL guide.

Is it the site, or only email?

Owners often report an outage while the page loads perfectly and form messages never arrive. That is a different fault: the application sends mail over SMTP, and when the outgoing server rejects the connection the page stays healthy while messages vanish silently. Check the send log, send a test to an outside address, and confirm the password and port. Do not ask support to "fix the site" before deciding whether the problem is inbound or outbound.

A common mistake: changing everything at once

At the first sign of trouble some people change the password, then the theme, then plugins, then DNS records, all within ten minutes. The result is that nobody knows which change fixed the fault, or which one added a second fault on top of the first. Copy the file you are about to edit, change one thing, then test. If it does not work, restore the copy before the next attempt.

What to prepare before contacting support

One organised message beats ten scattered ones. Prepare: roughly when the outage started, the exact URL that failed, the status code you saw, a screenshot, the uptime tool result, and a list of anything you changed in the last hour (template update, plugin, DNS edit). The question that shortens most conversations is: "what changed last?" In the large majority of incidents, the fault began minutes after it.

Prevention after the site returns

Monitor from an external service, keep a backup outside the server, and check the certificate a week before it expires. The goal is not preventing every outage but cutting detection time from "when a visitor complains" to "before anyone notices". The site-health card in your account panel shows service status and the last backup, so check it after every significant change.

Bottom line

Work from outside in: does it work for others, then domain, then DNS, then server, then application, then database. Each layer has a tool that is clearer than most people assume. And "what changed last" comes before everything else.