Site down but the host says the server is fine: hosting problem or code problem?

The symptom

Visitors get an error instead of your site, yet the hosting provider's status page is green and support tells you "the server is up, it's not us." The failure can look like a spinning tab that never resolves, a browser security warning, a blank white page, or a generic "500" error. Often it started after a deploy, a domain renewal, a certificate expiry, or a plugin/dependency update. The confusing part is that "the server is fine" and "the site is down" are both true at the same time — because the server hardware and the software running on it are different things.

What it usually means

A green server means the machine is powered on and reachable; it says nothing about whether your domain points at it, whether the certificate is valid, or whether your application booted. In practice the cause falls into one of four buckets: DNS (the name no longer resolves to the right IP), SSL/TLS (an expired or mismatched certificate), the web server/reverse proxy (Nginx/Apache up but the upstream app is dead, giving 502/504), or the application runtime itself (an uncaught exception, a failed migration, a missing environment variable). Hosting support is usually right that the box is healthy — the break is one layer up.

What we check first

We work outside-in, from the domain toward the code. 1) Resolution: `dig +short yourdomain.com` (or `nslookup`) — does it return the expected IP? 2) Reachability: `curl -I https://yourdomain.com` — read the HTTP status line. 200/301/302 = app answering; 502/504 = web server up but app down; connection refused/timeout = network or firewall. 3) Certificate: `openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | openssl x509 -noout -dates` to read notBefore/notAfter, or check for `NET::ERR_CERT_DATE_INVALID` in the browser. 4) Application logs — the decisive step: PHP-FPM/Apache at `/var/log/nginx/error.log` and `/var/log/php*-fpm.log`; Node/PM2 via `pm2 logs` or `journalctl -u yourapp`; Docker via `docker logs <container>`. A real stack trace or "Error establishing a database connection" there confirms it is code/config, not hosting.

What you can safely check yourself

You can gather the evidence without breaking anything. Note the exact error text and HTTP code (a screenshot of the browser console and Network tab helps). Try the site on mobile data as well as Wi-Fi, and via an incognito window, to rule out local caching or your own network. Use a free external checker (e.g. "is it down for everyone" style tools or an SSL checker) to confirm it's down globally, not just for you. Check whether your domain or certificate recently expired in your registrar/host panel — a lapsed renewal is one of the most common "server is fine" outages.

What NOT to touch

Do not start editing DNS records, changing nameservers, or re-pointing the domain on a hunch — a wrong A record or nameserver change can take up to 24–48 hours to propagate and turns a five-minute fix into a two-day outage. Don't delete or "reinstall" the SSL certificate blindly, and never rush a re-deploy or `git push` to production hoping it clears the error, as that can overwrite the last working state. Avoid clearing databases, running untested migrations, or toggling PHP/Node versions in the host panel. If you can, do not restart services repeatedly — it discards the in-memory logs that reveal the real cause.

What a 30-minute diagnosis can determine

In one focused session we can almost always name the layer at fault and hand you a clear verdict. We confirm whether DNS resolves correctly, whether the certificate is valid and covers the right hostname, whether the web server is returning the app's response or its own error, and whether the application actually started. From the logs we identify the failing component — expired cert, dead upstream, database connection refused, a fatal error from the last deploy — and tell you whether it's a quick fix or needs deeper work. You leave the 30 minutes knowing exactly what broke and who needs to act, instead of being bounced between your host and your developer.

When it becomes a bigger job

It grows beyond a diagnosis when the root cause is structural rather than a single toggle: a database that is corrupted or out of disk, a botched deploy that needs a controlled rollback, a dependency or runtime upgrade that broke compatibility, or a certificate/DNS setup that needs to be rebuilt properly (for example moving to automated Let's Encrypt renewal so it can't silently expire again). If the outage was caused by a security incident or an unattended migration, remediation and hardening follow. In those cases we scope the work with you first — but the 30-minute diagnosis still tells you which of these you're dealing with.

Frequently asked questions