Telling a host problem from a site problem

One question separates the two faster than any other: how wide is the blast radius? A fault in the hosting environment has poor manners about scope. It takes out every site on the account, or every account on the machine, and it is indifferent to which framework you run. A fault in your own application is precise: one site, often one route, one logged-in state, and it usually began at a timestamp somebody can name. Test scope first, then timing, then network, then file type.

Look at your own change log before anything else

The base rate here is lopsided, so honest ordering matters. Most incidents that arrive as "the server is down" close as a deploy, a plugin auto-update, an expired API token, a cron job that fired an hour off, or a record edited last week that has only now reached the resolver you happen to be using. Starting on your own side is not deference to the provider. It is playing the odds, and it costs you three minutes: read the last twenty commits, the update history of the CMS, and anything scheduled that runs on a weekly or monthly cadence.

Four tests that actually discriminate

The ladder, in order

1. Request a trivial static file you uploaded earlier, say /healthcheck.txt with one word in it. If it serves, the web server, the certificate and the path to you are all working, and suspicion moves inward.
2. Request a minimal dynamic file beside it: one line of output, no database, no framework bootstrap. If that runs and your application does not, the runtime is fine and your code or its dependencies are not.
3. Add a third file that only opens a database connection and closes it. This is where saturation and credential problems separate cleanly from template bugs.
4. Repeat step one from a network you do not control. Phone off wifi is enough.
5. Load a sibling site on the same account. Same result means the machine, different result means you.

Signals that genuinely point at the environment

• Unrelated tenants of the same box fail in the same minute: a static page, a CMS and a bare script, none of which share a line of code.
• Timeouts rather than errors, arriving in waves, with the same URL fast on retry. Intermittent failure under load is a resource pool running dry, not a code path, because a code path fails every time.
• The error belongs to a layer above your software: gateway codes from the proxy, resource limit notices, connections reset before a single byte of your response.
• Nothing at all in your application log for the failed request. If the request never reached your code, your code did not break it.
• Recovery happens without you deploying anything.

What to hand over when you escalate

Attribution work is not wasted even when the answer is the environment, because it turns a vague complaint into a ticket somebody can act on. Send timestamps in UTC, the full failing URL, the address you tested from, the raw error text, and the results of the static and dynamic checks above. State plainly what you have already ruled out. If the evidence points at the machine and you want a second pair of eyes on it, contact us with that bundle. Wider habits for spotting these patterns early live in running your estate.