Website Down? What to Check First, In Order

The symptom

The site that worked yesterday now shows nothing useful: a spinning tab that never loads, a blank white page, a browser error like "This site can't be reached", or a plain-text message such as "502 Bad Gateway" or "Error establishing a database connection". Sometimes it's intermittent — fine on your phone, dead on your laptop, or up for some visitors and down for others. The panic usually comes from not knowing whether you've lost the domain, the server, or just the app. Each of those is a different problem with a different fix, and the error text is your first clue about which one it is.

What it usually means

An outage almost always traces back to one of four layers. DNS: the domain no longer resolves to an IP address (typical after an expired domain, a changed nameserver, or a bad record) and you'll see DNS_PROBE_FINISHED_NXDOMAIN. SSL: the certificate expired or is misconfigured, giving NET::ERR_CERT_DATE_INVALID or ERR_SSL_PROTOCOL_ERROR while the site is technically still up on HTTP. Hosting/server: the machine is off, overloaded, or the web server (Nginx/Apache) stopped, producing 502/503 or a connection timeout. Application: PHP, Node, WordPress or the database crashed, giving a 500 error or a WordPress-specific database message while the server itself answers fine.

What we check first

We work outside-in, one layer at a time. First, DNS: run `dig example.com +short` or `nslookup example.com` — no IP returned means a domain or DNS problem, and a whois lookup shows if the domain simply expired. Next, connectivity and server: `curl -I https://example.com` returns the HTTP status header — a 200/301 means the server is alive, a 502/503 points at the web server or upstream app, and a hang means the host isn't answering. For SSL, `curl -vI https://example.com` prints the certificate's expiry date. If the server answers but the app errors, we open the logs — Nginx at /var/log/nginx/error.log, Apache at /var/log/apache2/error.log, and PHP-FPM or the app's own log — because the real stack trace lives there, not in the browser.

What you can safely check yourself

Confirm it's not just you: load the site on mobile data and through a third-party checker before assuming a global outage. Check your domain hasn't expired — your registrar dashboard shows the renewal date, and this catches a surprising share of "total" outages. Look at the exact browser error and note it down word for word; "certificate expired" and "can't be reached" send us in completely different directions. If you have a hosting control panel (cPanel, Plesk) or a status page from your provider, glance at it for a known incident. These checks are all read-only and safe.

What NOT to touch

Do not change DNS or nameserver records on a hunch — DNS edits can take up to 24-48 hours to propagate, so a wrong change turns a five-minute fix into a two-day outage. Don't delete plugins, themes, or files, and don't "reinstall" WordPress or your app to make an error disappear; you can destroy the evidence needed to diagnose it, or the data itself. Avoid forcing certificate renewals repeatedly, as some providers rate-limit issuance (Let's Encrypt will lock you out after too many attempts). And never restore an old backup over a live site before someone has confirmed what actually broke — you may overwrite good data to fix a problem that was never in the files.

What a 30-minute diagnosis can determine

In half an hour we can almost always tell you exactly which layer failed and what the fix involves. A few commands — `dig`, `curl -I`, a certificate check, and a read of the server and application logs — isolate whether it's DNS, SSL, hosting, or the application, and whether it's a quick reset or a deeper repair. You get a clear, plain-language answer: what broke, why, the estimated effort to fix it, and whether your data is at risk. Often the same diagnosis includes the fix, because expired certificates, stopped services, and crashed processes are frequently resolved within that window.

When it becomes a bigger job

It grows beyond a quick fix when the outage is a symptom rather than the cause: a hacked or defaced site, a database corrupted beyond a simple restart, or a server that keeps falling over under load or running out of disk. Recurring 500s that come and go usually mean an application-level bug or a resource limit that needs proper investigation, not a restart. A recovery that requires restoring from backups, migrating hosts, or rebuilding a compromised environment is a scoped project — but it still starts with the same 30-minute diagnosis, so the repair is aimed at the real cause instead of guesswork.

Frequently asked questions