Common causes of website downtime, and how to spot them
Websites do not crash for one reason. They crash for many small reasons that, with the right clues, you can usually narrow down in minutes.
Server overload from a traffic spike
When a story goes viral, a small site can be flooded with visitors. The server has a fixed amount of memory and processing power. When too many requests arrive at once, the server slows down, queues requests, then starts returning errors.
Clues that point to overload include slow page loads at first, then 502 or 504 errors, then complete timeouts. The pattern is gradual, not instant. The fix is more capacity, a content delivery network, and caching.
DNS provider outage
DNS is the directory that turns domain names into IP addresses. If the DNS provider goes down, browsers can not find the site even if the server is fine. This has caused some of the biggest outages on the internet.
Clues that point to DNS include error messages such as DNS_PROBE_FINISHED_NXDOMAIN or server not found. If only sites using one DNS provider are affected, that is the smoking gun.
A bad deploy
Many outages are self inflicted. A new release goes out, breaks something, and the site stops working. The cause can be a code bug, a missing environment variable, a bad database migration, or a feature flag flipped the wrong way.
Clues that point to a bad deploy include the timing matching a known release, working endpoints suddenly failing, and a status page note about a recent change. The fix is to roll back to the previous version.
Database problems
Many sites store everything in a database. When the database is slow or down, the site is slow or down. Causes include a query that locks too many rows, a disk that has filled up, a runaway background job, or a failover that did not complete.
Clues include the homepage loading fine while logged in pages or search pages fail. That pattern often means the cached front page works, but anything that hits the database does not.
Third party services
Modern sites depend on many outside services for payments, authentication, fonts, analytics, search, comments, and more. If any of those services fail in a way the site does not handle well, the whole page can break.
Clues include the site loading partly but a key feature like login or checkout being broken. Browser developer tools, opened with the keyboard shortcut to view the console, often show specific error messages naming the failing service.
SSL certificate expired
Every HTTPS site has a certificate. Certificates have an expiration date. If nobody renews it, browsers refuse to load the site and show a security warning. This is one of the most common avoidable outages.
Clues include a clear browser error such as NET::ERR_CERT_DATE_INVALID. The fix is to renew the certificate. Most teams now use automatic renewal with Let's Encrypt or their hosting provider.
DDoS attack
A distributed denial of service attack floods a site with junk traffic from many machines at once. The goal is to make the site too busy to serve real visitors.
Clues include a sudden traffic spike from many different countries, unusual user agents, and patterns that do not match real users. The fix usually involves a service like Cloudflare that absorbs and filters the bad traffic.
Cloud region outage
Most sites run in one cloud region, such as US East or Europe West. If that whole region has a problem, every site in it can go down at the same time.
Clues include many unrelated sites going down at the same time and the cloud provider's own status page showing red. The fix at the cloud level is for the provider to bring the region back. The fix at the site level is to run in multiple regions, which is expensive.
Power, network, and weather events
Data centers run on power and network. Both can fail. Storms, fires, fiber cuts, and even animals chewing through cables have brought down major services.
Clues are usually obvious in retrospect because the news will report a major incident. There is not much an individual user can do except wait.
How to narrow down the cause in five minutes
Use this short script:
- Confirm the site is down with QuickUptime or a similar checker.
- Check the company's status page and social media.
- Try a different network like mobile data to rule out your own connection.
- Open developer tools and look at the network and console tabs for clues.
- Look at the timing. Did the outage start during a known release or a known incident?
For a casual user, the goal is just to know whether to wait, retry, or move on. For a site owner, the same steps point at the root cause faster than guessing.