Website unavailable: causes, diagnosis and immediate action

Confirm who is affected, then examine DNS, connection, TLS and HTTP in order. Restore a known safe service, preserve evidence and communicate clearly; afterwards address the technical and organisational causes.

Similar browser symptoms can have different causes

A page that never loads, shows an error or returns blank content can look equally unavailable to a visitor. The web server may have stopped or overloaded after a release or traffic spike, a domain may resolve to the wrong destination, or code, plugins, configuration or exhausted resources may produce HTTP 500, 502 or 503 errors.

Check from an external network to distinguish local from wider failures, inspect the relevant Nginx, Apache or container service and review recent updates or configuration changes. Production impact makes fast structured diagnosis preferable to improvisation.

Availability is a chain of dependencies

Between browser and application are DNS, network, TLS, CDN or reverse proxy, web server, runtime, database and external services. First determine whether the incident is global, regional, provider-specific or limited to one device. Then check resolution, TCP connectivity, certificate and HTTP response.

A 502 or 504 differs from DNS NXDOMAIN or an application-generated 500. Correlation IDs and timestamps link the visitor's experience to server logs. A deployment, DNS, firewall, certificate or database change just before the incident is a useful clue, not proof by itself.

Stabilise during the incident

The first objective is a safely restored service. A known-good rollback, disabling a broken feature or switching to a healthy instance can be better than a complex repair under pressure. Log each action, time, owner and result.

Communicate the affected function, start time, user impact, present status and next update. Keep speculation out of public messages. If compromise is suspected, preserve evidence and restrict access before uncontrolled changes erase logs or alter systems.

Use the postmortem to improve the system

Separate the trigger, technical cause and organisational amplifiers. Missing tests, unclear ownership, weak resource limits and late alerts can be as relevant as the failed process. Give corrective actions an owner, deadline and verifiable success criterion.

Synthetic checks from several locations, real-user metrics, structured logs and distributed traces can shorten future diagnosis. Useful observability identifies which dependency fails, since when and for which users, rather than only reporting that a page is down.

Practical checklist

01
Confirm scope with external monitoring and more than one network.
02
Check DNS, connection, TLS and HTTP in order.
03
Correlate recent changes, infrastructure metrics and application logs.
04
Prioritise and record a safe rollback or containment action.
05
Complete a postmortem with causes, actions, owners and deadlines.

Frequently asked questions

What is the difference between 502 and 504?

Both commonly come from a gateway or proxy. A 502 indicates an invalid or failed upstream response; a 504 indicates that the wait for the upstream exceeded its timeout.

When should we contact the provider?

When measurements locate the failure outside the layer you control or the provider confirms an incident. Times, traces and your diagnostic evidence help escalation.

Website unavailable: causes, diagnosis and immediate action

Knowledge you can put to work.