Common Causes of Website Downtime

When a website goes down, the first instinct is to guess the cause. Restart the server. Roll back the release. Call the host. Sometimes that works. More often it wastes the first twenty minutes.

A better start is to say exactly what you are seeing. The symptom narrows the cause to one or two layers, and each layer has its own first check. This guide is built around that idea. For the definition of downtime and its effects, see website downtime.

Is it down for everyone?

Before you change anything, find out who is affected.

• Open the site from a phone on mobile data, not your office network.
• Look at what your monitoring recorded: when the first failure happened and what the reason was.
• Ask a colleague in another place to try.
• Check whether only one page, one country, or one device type fails.

If only you see the problem, the cause is likely local: your network, a cached DNS answer, a VPN, or a browser extension. If everyone sees it, continue below.

From symptom to first check

RFC 9110 defines the three gateway codes. A 502 means a gateway or proxy received an invalid response from the server behind it. A 503 means the server cannot handle the request now, usually from overload or maintenance, and may include a Retry-After header. A 504 means the gateway did not get an answer in time. In all three, the front door is open and the problem sits further in.

Commands for a first look

From any machine with a terminal:

curl -I https://example.com/

This prints the status line and headers without the body. For more detail, including the DNS lookup, the connection, and the certificate step, add -v:

curl -v https://example.com/ -o /dev/null

Where the output stops tells you where it fails. If it stops before "Connected", the problem is the name or the network. If it stops during the certificate step, look at the certificate. If you get a status line, the server answered, and the status tells you the next step.

Server and hosting

The machine can be off, out of memory, out of disk space, or overloaded. A full disk is a quiet one: databases stop writing, logs fill up, and the application starts failing in odd ways.

Check the host's status page first, then the machine itself: running processes, memory, disk, and load. A cloud provider's own incident can look identical to your own failure, so look at their status page before you spend an hour on your configuration.

Application and deployments

A failed release is among the most common causes of an outage that starts at a precise minute. If the failure began right after a deployment, roll back first and investigate afterwards.

Typical signs are 500 errors, a blank page, or an application that starts and then exits. The application log at the moment of the first failure usually names the exception. A new dependency that is not installed, a missing environment value, and a database change that the code does not expect are frequent causes.

Proxies, load balancers, and CDNs

Many sites sit behind a reverse proxy, a load balancer, or a content delivery network. When the proxy works and the server behind it does not, visitors see 502 or 504, often on a page branded by the proxy. That branding tells you the front layer is alive, and you should look behind it.

Look at the proxy's own log for the upstream error. A proxy timeout shorter than the application's slowest request will produce 504 errors even though the application is healthy.

DNS and the domain

If the name stops resolving, the site is unreachable however healthy the server is. Causes include a deleted record, a changed name server, a provider outage, and an expired domain.

Follow How to Troubleshoot DNS Resolution Errors to find the layer, and check the registration with How to Check When a Domain Expires.

Certificates

An expired certificate, or one issued for a different name, makes browsers show a full-page warning. The server is running, but visitors will not get through. Check the dates and the names on the certificate. The cause and the prevention are covered in How to Prevent SSL Certificate Expiration.

Overload

A traffic spike, a heavy background job, or a search engine crawling too fast can use up all capacity. Signs are slow pages first, then 503 or 504 errors, then timeouts. It often recovers without intervention and returns at the next peak.

Look at the load graph over the minutes before the first failure. If response times climbed steadily before the outage, overload is likely.

Third-party services

A page can load while one function fails: payment, login, search, or a map. The service behind it is down or slow. From outside, the site looks up. Read the error the application logs about the failing call, and check the provider's status page.

What a monitor can tell you

An outside check, such as UptimeWire's, requests the address and reads the answer. For a failed check, it records a reason. The reasons it distinguishes include:

• the domain name could not be resolved,
• the connection failed,
• no answer within 15 seconds,
• the TLS certificate or connection is not valid,
• the server answered with a given status code,
• the expected text was not found on the page.

That reason sends you to the right row in the table above before you open a server. UptimeWire opens an incident after three failed checks in a row, about 20 seconds apart, and keeps the reason with it. See How to Monitor Website Availability for the setup.

A check that reads a status code cannot see a login that rejects every password. See also why monitors send false alerts for the opposite problem.

After the recovery

Once the site answers again, write down:

• the time of the first failure and the time of recovery,
• the symptom and the cause,
• what fixed it,
• what would have made you notice sooner.

Those four lines are enough to turn one outage into something the next person can use.

Checklist

• Say the symptom in one sentence.
• Check whether everyone is affected.
• Read the recorded failure reason.
• Run curl -v and see where it stops.
• Check the last deployment or change.
• Check DNS, the domain, and the certificate, which fail without any change on your side.
• Write down the cause and the fix.