A small business website can go down because of a hosting problem, DNS error, expired certificate, failed deployment, overloaded server, broken API or network issue. Sometimes the cause is obvious. Sometimes everything appears healthy until customers start reporting that something isn't working.You don't need AWS's infrastructure or Meta's millions of users to experience the same categories of problems.That's where website performance monitoring becomes important. Looking only for a complete “up” or “down” state can miss problems that are already affecting visitors.Resolving the original DynamoDB problem did not immediately end the outage.The internet can make a website feel almost permanent. You type a familiar address, the page loads, and you rarely think about everything happening behind the scenes to make that possible.
But even the companies operating some of the world's most sophisticated digital infrastructure experience outages.
A routing change can make a large portion of a network unreachable. A software update can take critical systems offline. A failure at one cloud provider can affect services built by another. And sometimes, a problem that begins in one component can spread through several connected systems before anyone realizes how large it has become.
For businesses that depend on their websites every day, those incidents are worth studying. Farsafe helps businesses monitor website availability and performance, but monitoring is only one part of the bigger reliability picture. The more useful question is: what can we learn from the failures of the world's biggest internet companies?
Why Major Website Outages Are Worth Studying
A major outage is more than a story about a website being unavailable. It can reveal weaknesses in configuration management, infrastructure design, third-party dependencies, monitoring, recovery procedures, or the way different services depend on one another.
It also shows why uptime is more complicated than simply asking whether a server is online. A website can be technically reachable while users in one region cannot access it, pages take too long to load, or a critical feature stops working.
If you want to understand the fundamentals behind website uptime, Farsafe's guide explains what uptime means, how it is measured, and why it matters to a business.
The following incidents show how those problems can play out at a much larger scale.
Six Major Outages That Reveal How Websites Fail
Cloudflare — June 2022: When 4% of the Network Handled Half the Requests
On June 21, 2022, Cloudflare experienced an outage that affected traffic in 19 of its data centers.
At first glance, 19 locations might not sound like a huge portion of a global network. The important detail was where those locations sat within Cloudflare's infrastructure. Cloudflare said the affected facilities represented only about 4% of its total network, but they handled approximately 50% of its total requests.
The outage began at 06:27 UTC and all 19 data centers were back online by 07:42 UTC.
The cause was a network configuration change made as part of a project intended to improve resilience. A change to BGP prefix advertisement policies caused critical prefixes to be withdrawn, making the affected locations unreachable. The problem also disrupted internal load balancing and caused smaller compute clusters to become overloaded.
The lesson is bigger than “a configuration change caused an outage.”
Infrastructure isn't automatically resilient just because it is distributed.
Some parts of a system carry far more traffic or perform far more important functions than others. If those components become a concentrated point of failure, a relatively small infrastructure problem can have a disproportionately large effect.
Cloudflare's own postmortem also shows why controlled rollouts, testing and automated rollback procedures matter when making changes to critical infrastructure.
Google Cloud — September 2023: A Problem That Lasted 3 Hours and 46 Minutes
On September 12, 2023, several Google Cloud products experienced elevated error rates and request failures, primarily in the us-central1-a zone.
The incident lasted 3 hours and 46 minutes.
Affected products included Compute Engine, Persistent Disk, Google Kubernetes Engine, Bigtable, Dataflow, App Engine and Cloud SQL.
Google's incident report identified task failures in the caching proxy of its distributed lock service in the affected zone, associated with high memory usage. The incident also required careful recovery because the affected infrastructure was foundational to data-center operations.
What's interesting here is that the problem wasn't simply that one Google Cloud product stopped working.
A failure in foundational infrastructure can affect several services that depend on it.
Google specifically said it was reviewing procedures for high-volume internal changes, looking at ways to reduce recovery time, and improving the resilience of critical infrastructure against large load spikes.
For businesses, that distinction matters.
An outage has two clocks: how long it takes for something to fail, and how long it takes to detect, understand and recover from the failure.
Meta — March 2024: Millions of Reports From a Single Outage
On March 5, 2024, Facebook, Instagram and other Meta services experienced a widespread disruption.
According to Internet Society's analysis of Downdetector data, Facebook generated more than 11.1 million reports from users around the world. Instagram generated roughly 3.3 million reports, while WhatsApp generated around 2 million.
Those figures should be understood as reported outage incidents, not a precise count of individual people affected.
The scale is what makes this incident particularly useful to study. A problem affecting one major platform can quickly become a problem affecting several connected services that millions of people use at the same time.
The broader lesson is that users don't necessarily experience an infrastructure problem in the same way the company does.
A company may see a network, authentication or configuration issue inside its infrastructure. The customer sees something much simpler:
“I can't log in.”
That's why availability monitoring needs to be connected to the actual customer experience, not just the health of an individual server.
The 2024 outage was ranked as the largest global outage in Internet Society's Downdetector-based review of the year.
CrowdStrike — July 2024: When a Software Update Became Everyone's Problem
The CrowdStrike incident of July 19, 2024 is different from a conventional website outage, but it may be one of the most important examples for understanding modern digital reliability.
A faulty automatic update from CrowdStrike caused Windows systems around the world to crash. The disruption affected organizations across industries, including airlines, healthcare, emergency services, government services and other businesses.
Internet Society described the incident as a failure of systems using a particular operating system and vendor management tool rather than an internet connectivity outage. Its analysis of Downdetector data recorded nearly 5 million reports to services that relied on CrowdStrike or Microsoft systems connected to the incident.
The important lesson isn't simply that a software update can go wrong.
It's that modern businesses rarely operate alone.
Your website may depend on a hosting provider, cloud platform, CDN, DNS provider, security service, payment processor, authentication system or external API. If an important dependency fails, your own servers can remain healthy while your customers still experience a broken service.
That makes dependency risk one of the most important reliability lessons of the past few years.
Cloudflare — June 2025: The Dependency Behind the Dependency
Cloudflare provided another useful example in June 2025.
On June 12, Cloudflare experienced a major service disruption lasting 2 hours and 28 minutes. Several services were affected, including Workers KV, WARP, Access, Gateway, Images, Stream, Workers AI and Turnstile.
The direct trigger was a failure in infrastructure supporting Workers KV. That infrastructure included a component provided by a third-party cloud provider. Because Workers KV was a critical dependency for multiple Cloudflare products, the failure spread beyond the original component.
Cloudflare was explicit about the lesson in its postmortem: although the third-party provider's failure was the immediate trigger, Cloudflare considered the dependency and the architecture built around it ultimately its responsibility.
That is an important distinction for any business owner.
Using a third-party service doesn't transfer responsibility for your website's reliability.
You may not control whether a provider experiences an outage, but you can understand which services your website depends on, identify critical failure points and make sure you know when something stops working.
AWS — October 2025: How One Failure Can Trigger Another
The AWS outage of October 20, 2025 provides perhaps the clearest modern example of a cascading failure.
The incident began with DNS resolution problems involving regional DynamoDB service endpoints in AWS's US-EAST-1 region.
Resolving the original DynamoDB problem did not immediately end the outage.
AWS reported that other services began experiencing problems because EC2 instance launching depended on DynamoDB. Network Load Balancer health checks were subsequently impaired, creating connectivity problems affecting services including Lambda, DynamoDB and CloudWatch.
AWS gradually recovered the affected systems, with Network Load Balancer health checks restored at 9:38 AM PDT and all AWS services returning to normal operations by approximately 3:01 PM PDT. Some services still had backlogs to process afterward.
The sequence is what makes this incident so valuable to study:
DNS problem → DynamoDB problem → EC2 dependency problem → load-balancer problems → additional service disruption
The original failure and the final customer impact were not the same thing.
And that is one of the most important lessons from major internet outages: systems don't always fail one component at a time. They can fail through relationships between components.
What These Outages Have in Common
The companies and incidents are different, but the underlying problems start to look surprisingly familiar when you put them side by side.
Configuration changes can have a much bigger impact than expected
Several major outages began with a change that seemed manageable at the time.
The problem isn't necessarily that changes are made. Websites and infrastructure need constant updates. The risk comes when a change affects a critical dependency, reaches more systems than expected, or isn't easy to roll back.
Cloudflare's 2022 outage is a good example. A change affecting network routing reached infrastructure responsible for a disproportionately large amount of traffic.
For a smaller business, the equivalent could be a DNS change, hosting configuration, plugin update, deployment or firewall rule. The scale is different, but the basic failure pattern is similar.
Third-party services can become part of your outage
The CrowdStrike incident and Cloudflare's 2025 outage demonstrate another reality of modern websites: your website may depend on systems you don't control.
A business might use one provider for hosting, another for DNS, another for payments, another for authentication and several external APIs. Each dependency can introduce another possible point of failure.
That doesn't mean businesses should avoid third-party services. It means they should know which dependencies are critical and understand what happens if one of them becomes unavailable.
One failure can trigger another
The AWS incident is a particularly clear example.
The initial DNS-related problem wasn't the end of the story. Dependencies between AWS services meant that the original failure contributed to additional problems elsewhere in the platform.
This kind of cascading failure is difficult to understand from the outside. A customer doesn't see the individual components. They simply see a website, app or checkout that isn't working.
That's why troubleshooting an outage requires looking beyond the first obvious symptom.
Being online isn't the same as working properly
There is another lesson that is easy to miss.
A website doesn't have to be completely offline to create a bad customer experience.
It might load slowly, fail intermittently, return errors on particular pages or work normally in one location while failing in another.
That's where website performance monitoring becomes important. Looking only for a complete “up” or “down” state can miss problems that are already affecting visitors.
Detection time matters
Finally, every outage raises the same practical question:
How quickly did someone know there was a problem?
A business cannot respond to an outage it hasn't detected.
That doesn't mean every website needs to be checked every few seconds. The appropriate website monitoring frequency depends on how important the site is, how quickly downtime affects the business and how much time the company can reasonably spend responding to an incident.
For an ecommerce store, booking platform or SaaS application, a delay of several minutes may matter much more than it would for a simple informational website.
What Can a Small Business Learn From These Outages?
You don't need AWS's infrastructure or Meta's millions of users to experience the same categories of problems.
A small business website can go down because of a hosting problem, DNS error, expired certificate, failed deployment, overloaded server, broken API or network issue. Sometimes the cause is obvious. Sometimes everything appears healthy until customers start reporting that something isn't working.
The first lesson is to know what matters most on your website.
If your website only provides basic company information, a short outage may be inconvenient. If customers use it to place orders, make bookings, submit forms or access an application, availability becomes much more important.
The second lesson is to detect problems before customers have to report them.
A monitoring system can periodically check whether your website responds, how quickly it responds and, depending on the monitoring setup, whether it is reachable from different locations.
The third lesson is to think beyond the website itself.
Your homepage might be working while your checkout, login system or API is failing. Monitoring the parts of the service that matter to customers can give you a much clearer picture of actual availability.
And finally, don't wait until an outage happens to decide what to do. A simple response plan can make a stressful incident much easier to manage.
If you're looking for practical ways to reduce website downtime, the first step is identifying the most likely failure points and deciding how quickly you need to know when something goes wrong.
Downtime also has a business cost beyond the minutes shown on an uptime report. Lost transactions, missed leads and frustrated customers can make even a relatively short incident significant. Understanding the cost of website downtime can help put that risk into perspective.
How Monitoring Helps Reduce the Impact of an Outage
Monitoring cannot guarantee that a website will never go down. Even companies with enormous engineering teams and highly redundant infrastructure experience failures.
What monitoring can do is reduce the time between something going wrong and someone knowing about it.
For a business website, that can make a meaningful difference.
Start with availability
The most basic check is also one of the most useful: can someone reach your website?
Regular availability checks can alert you when a website stops responding or begins returning errors. Instead of waiting for a customer to send a message saying, “Your website isn't working,” your team can start investigating as soon as the problem is detected.
Look beyond a simple up-or-down check
A successful response doesn't always mean everything is working properly.
Response times can gradually increase before a complete failure occurs. A particular service or page may also fail while the homepage continues to load normally.
That's why website performance monitoring can complement basic uptime checks. Tracking response times and performance trends can help reveal problems that a simple availability check might not catch.
Monitor from more than one location
A website can appear available from one network while users in another region are experiencing problems.
Multi-location monitoring helps distinguish between a problem with the website itself and a regional connectivity or routing issue. For businesses serving customers in different cities or countries, that distinction can be particularly useful.
Make alerts actionable
An alert is only useful if someone knows what to do with it.
Businesses should decide in advance:
- Who receives outage alerts?
- Which problems require immediate attention?
- How should the incident be investigated?
- Who communicates with customers if the outage continues?
- When should the incident be reviewed afterward?
A clear process can prevent an unexpected outage from turning into an unnecessarily long response.
What Should You Do When Your Website Goes Down?
When an alert arrives, the first instinct may be to start changing things immediately. It's usually better to pause for a moment and confirm what is actually failing.
Start by checking whether the website is unavailable everywhere or only from a particular location. Then look at the basics: DNS, hosting, SSL, recent deployments or configuration changes.
If the website is reachable but a particular feature isn't working, investigate the application and any third-party services that feature depends on.
It's also useful to check whether anything changed shortly before the problem began. A recent deployment, DNS update, plugin change or infrastructure modification can provide an important clue.
If you're working through an outage and need a structured starting point, Farsafe's website downtime troubleshooting checklist covers common causes and the first checks worth making.
Once the immediate problem is resolved, don't simply close the incident and move on. Record what happened, how long the disruption lasted, how it was detected and what could make the next response faster.
Final Takeaway
The biggest website outages of the past few years have involved some of the world's most sophisticated technology companies. Yet the lessons they reveal are surprisingly practical.
Configuration changes can fail. Dependencies can break. One problem can trigger another. And a website can experience serious performance problems long before it becomes completely unavailable.
No monitoring system can eliminate every one of those risks.
But businesses can make sure they aren't discovering an outage at the same time as their customers.
The goal isn't to promise that your website will never go down. It's to know when something has gone wrong, understand what is happening, and respond as quickly as possible.