Hosting, DNS & Deployment Support — Get Your Site Back Online

Situations we get called in for

• Your site shows a blank white page, a 500 or 502/503 error, while the hosting panel says everything is running.
• The domain no longer resolves, points to the wrong place, or still shows the old host after a migration — a DNS or propagation problem you can't pin down.
• Browsers block the site with "Not secure", "certificate expired" or NET::ERR_CERT — the SSL certificate lapsed or auto-renewal (Let's Encrypt) stopped working.
• A deployment went wrong: the last push, plugin update or dependency install broke the live site and there's no clean way back.
• The application throws errors — PHP fatal errors, a Node process that keeps crashing or restarting, out-of-memory — while the server itself is fine.
• You changed hosts or the previous provider disappeared, and now the site works locally but breaks in production with no one to ask.
• "It works on my machine" but not on the server: wrong runtime version, missing environment variable, file permissions or a path that only exists locally.
• The site is intermittently down or painfully slow, and you can't tell if it's the server, the database, the network or the code.
• Email from your domain stopped sending or lands in spam after a DNS, MX or SPF/DKIM change.
• You need a deployment or migration done safely — staging, cutover, rollback plan — without gambling with the live site.

How we diagnose it — in order

1. We reproduce and locate the failure first. Is the site truly down, or only for some users? We check the HTTP status the server actually returns (200 vs 500/502/503), test from outside your network, and separate a name-resolution problem from an application problem before touching anything.
2. We resolve the DNS and TLS layer. We check what the domain actually resolves to (dig/nslookup), whether A/CNAME/MX records and nameservers are correct, if propagation is still in flight, and whether the SSL certificate is valid, expired or failing to auto-renew — then fix the record or the certificate chain.
3. We check the web server and runtime. Nginx or Apache config, virtual host, ports and reverse-proxy rules; then the runtime behind it — the PHP-FPM pool, the Node process and its manager, version mismatches, memory limits and timeouts that produce 502/504.
4. We read the logs — this is where the truth is. Server access/error logs, PHP error log, application and deployment logs, systemd/pm2 output. The exact error message (a fatal, a missing module, a permission denied, a failed migration) tells us the real cause instead of a symptom.
5. We inspect the deployment and environment. What changed in the last release, whether env variables and secrets are present, file ownership and permissions, build artefacts, and whether a rollback to the last known-good state is the fastest safe path.
6. We fix, verify and harden. We apply the fix, confirm the site returns 200 end-to-end, then close the gap that caused it — certificate auto-renewal, a health check, a safer deploy/rollback step — and hand you a short written note of what broke and why.

Frequently asked questions

See also

• Emergency Website & App Support →