It started the way most digital disasters do—quietly, almost innocently. At 6:20 AM Eastern Time on Tuesday, November 18, 2025, developers around the world began noticing something strange. Websites weren't loading. APIs were timing out. Error messages appeared where content should be.
And then, all at once, the internet broke.
The Morning Everything Stopped Working
Picture this: You're reaching for your morning coffee, opening your laptop to check the news on X (formerly Twitter), planning to queue up some Spotify for your commute, maybe tackle that design project in Canva. Instead, you're greeted with a cold, impersonal message:
Internal server error on Cloudflare's network
Error 500
You refresh. Nothing. You try ChatGPT—surely AI should be working, right? Nope. Same error. Claude AI? Down. Spotify? Unreachable. Even League of Legends players found themselves unable to connect to servers.
The weirdest part? When you went to check DownDetector to see if anyone else was having problems, DownDetector itself was down. It's like calling 911 only to find out the emergency services are also experiencing technical difficulties.
The Scale of the Collapse
Let me paint you a picture of just how widespread this outage was. The infrastructure service Cloudflare faced massive outages on Tuesday morning, cutting off access to ChatGPT, Claude, Spotify, X, and other platforms.
Here's a partial list of services that went dark:
AI & Productivity
- ChatGPT & Sora (OpenAI)
- Claude AI (Anthropic)
- Canva (design platform)
- Character AI
- Perplexity AI
Social & Entertainment
- X (formerly Twitter)
- Spotify (music streaming)
- Discord (communication)
- Letterboxd (film reviews)
- Archive of Our Own (fanfiction)
Gaming
- League of Legends
- Valorant
- Runescape
Business & Finance
- Shopify (e-commerce)
- Coinbase (cryptocurrency)
- Square (payments)
- Moody's (credit ratings)
- Indeed (job search)
Essential Services
- Uber & Uber Eats
- Zoom (video conferencing)
- NJ Transit (transportation)
- McDonald's (self-service kiosks)
- New York City Emergency Management (yes, really)
And the list goes on. Cloudflare says around a fifth of all global websites use some of its services. That's approximately 20% of the entire internet, all hanging by the same thread—and on Tuesday morning, that thread snapped.
The Human Impact: More Than Just Numbers
It's easy to look at this as just another tech glitch, but let's talk about the real-world consequences. One Reddit user posted a photo of a McDonald's self-service ordering kiosk showing the Cloudflare error. No ordering your morning McMuffin that day.
Developers couldn't access their documentation sites. Remote workers couldn't join Zoom meetings. Designers lost hours of productivity waiting for Canva to come back online. Gamers found themselves locked out of their favorite multiplayer games. People trying to book travel, order food, or simply scroll through their social media feeds were all equally stranded in digital purgatory.
And here's something that genuinely sent chills down my spine: According to comments, PADS (Personnel Access Data System), a background check site for nuclear plants, was also impacted by the Cloudflare outage, meaning visitor access to their respective nuclear plant was currently not available.
Think about that for a moment. Critical infrastructure security systems, dependent on a single service provider.
The Technical Breakdown: What Actually Happened
The issue was not caused, directly or indirectly, by a cyber attack or malicious activity of any kind. Instead, it was triggered by a change to one of Cloudflare's database systems' permissions which caused the database to output multiple entries into a "feature file" used by the Bot Management system.
In simpler terms: A configuration file that helps Cloudflare identify bots unexpectedly doubled in size. This bloated file was then automatically pushed out to all the servers in Cloudflare's massive global network. When these servers tried to read this unexpectedly large file, they choked. Traffic routing systems crashed. And suddenly, 20% of the internet was unreachable.
It's the digital equivalent of a traffic light in a major city getting stuck on red at every intersection simultaneously. Nothing malicious, just a cascading failure from one seemingly small change.
Cloudflare experienced a "spike in unusual traffic" shortly before errors broke out across many major websites it serves, which complicated the diagnosis. The company's engineering teams were thrown into emergency mode, trying to identify and fix the problem while the digital world watched and waited.
The Timeline: Four Hours That Felt Like Forever
6:20 AM EST - The outage begins. Early reports start trickling in.
7:48 AM EST - Cloudflare acknowledges the issue publicly, reporting "widespread 500 errors" and failures across its dashboard and API.
8:20 AM EST - Peak chaos. Over 11,000 users report Cloudflare issues on DownDetector alone. Multiply that across all affected services, and you're looking at millions of frustrated users worldwide.
9:42 AM EST - Cloudflare announces a fix has been implemented. Services begin slowly coming back online.
9:30 AM EST - Most major services report normal operations restored.
Total duration: Approximately 4 hours and 10 minutes of widespread disruption, with some services experiencing lingering issues for several hours after.
The Financial Carnage
Let's talk about money, because outages aren't just inconvenient—they're expensive.
Large enterprises lose an average of $5,600 to $9,000 per minute of downtime, with 93% of enterprises reporting downtime costs exceeding $300,000 per hour.
Do the math: Four hours of downtime affecting thousands of businesses simultaneously. According to website maintenance service SupportMy.website, an estimated $5 billion to $15 billion has been lost for every hour of the outage.
That's not a typo. We're talking about potential losses in the tens of billions of dollars globally. And that's just the immediate impact—not counting lost productivity, damaged reputation, or the scrambling costs of emergency response teams working overtime.
The Deeper Problem: Too Many Eggs in Too Few Baskets
Here's where things get uncomfortable. This wasn't the first major infrastructure outage this year, and it won't be the last. Amazon Web Services experienced a massive outage in October that took down Venmo, Disney+, Snapchat, and countless others. Microsoft Azure had its own incident.
Graeme Stuart, head of the public sector at cybersecurity firm Check Point, noted that many organisations run their operations through one route with no meaningful backup, meaning that there is no fallback if it fails. "The internet was meant to be resilient through distribution, yet we have ended up concentrating huge amounts of global traffic into a handful of cloud providers".
Signal president Meredith Whittaker used the outage to highlight exactly this problem: our modern internet, for all its apparent vastness, runs on surprisingly few pieces of critical infrastructure. Cloudflare, AWS, Microsoft Azure, Google Cloud—these companies form the invisible backbone of the digital world. When one stumbles, millions feel it.
What This Means for Developers (That's You)
If you're building anything for the web, this outage should be a wake-up call. Here are some hard truths:
1. Single Point of Failure = Single Point of Vulnerability
Relying entirely on one CDN, one cloud provider, or one service—no matter how reliable—is a ticking time bomb. Cloudflare is one of the most robust platforms in the world, with 99.99% uptime guarantees. And yet, here we are.
2. Redundancy Isn't Optional Anymore
Consider:
- Multiple DNS providers
- Multi-CDN strategies
- Geographic distribution across different infrastructure providers
- Graceful degradation when services fail
Yes, it's more complex. Yes, it costs more. But ask yourself: what would four hours of downtime cost your business?
3. Status Pages Are Critical
One of the most frustrating aspects of this outage was that Cloudflare's own status page was partially affected. If your users can't check if you know about the problem, confusion and frustration multiply exponentially.
4. The "Internet" Is More Fragile Than We Think
We treat the internet as this magical, always-on utility, like electricity or running water. But it's not. It's a complex, interconnected system of corporate services, any one of which can bring down huge swaths of the web.
The Irony of Modern Infrastructure
Here's something that struck me while researching this incident: Cloudflare exists primarily to protect websites from exactly this kind of disruption. They defend against DDoS attacks, optimize content delivery, and provide redundancy. Their entire business model is built on making the internet more resilient.
And yet, when their systems failed, they became the very thing they protect against—a single point of failure that brought down millions of sites.
It's not really their fault. Cloudflare runs an incredibly sophisticated operation. But it highlights a fundamental problem in how we've architected the modern web: we've traded distributed resilience for centralized efficiency.
The early internet was designed to survive nuclear war, with multiple redundant paths for every connection. Today's internet is designed for speed and cost-effectiveness, with traffic funneled through a handful of chokepoints for optimization.
What Cloudflare Did Right (And Wrong)
What They Did Right:
- Acknowledged the problem quickly (within 28 minutes)
- Communicated regularly with updates
- Implemented a fix within ~2 hours
- Published a detailed post-mortem explaining exactly what happened
- Showed transparency about the root cause
What Could Have Been Better:
- Their own status page was partially affected, making it hard to get official updates
- The fix took several hours to fully propagate across all services
- Some users experienced recurring issues even after the "fix" was announced
To their credit, Cloudflare stated "we are sorry for the impact to our customers and to the Internet in general. Given Cloudflare's importance in the Internet ecosystem any outage of any of our systems is unacceptable".
Lessons Learned: Building for the Next Outage
Because let's be real—there will be a next outage. Maybe not Cloudflare. Maybe AWS, or Azure, or Google Cloud. But it will happen.
Here's what we, as developers and architects, need to do:
1. Embrace the Chaos Monkey Philosophy
Netflix famously runs "Chaos Monkey," which randomly kills services in production to test resilience. Start thinking this way. What happens to your application if Cloudflare goes down? If your CDN fails? If your primary database disappears?
2. Build Graceful Degradation
Your site doesn't need to work perfectly without Cloudflare. But it should do something. Even if that's just showing a cached version or a simple static page explaining the situation.
3. Diversify Your Dependencies
- Use multiple DNS providers with automatic failover
- Consider multi-CDN setups for critical applications
- Keep static mirrors of essential content
- Implement service workers for offline functionality
4. Monitor Third-Party Dependencies
You can't control Cloudflare's uptime, but you can detect when it goes down and respond automatically. Set up monitoring that checks your actual user-facing services, not just your own infrastructure.
5. Have a Communication Plan
When services go down, your users need to know you know. Having a status page on completely separate infrastructure (not relying on Cloudflare or any other service you use) is essential.
The Bigger Picture: Internet Architecture in 2025
This incident reveals something profound about the state of the internet in 2025. We've achieved incredible things—AI that can write code, streaming services delivering 4K video to billions, real-time global communication. But we've built this technological marvel on a foundation that's increasingly centralized and, therefore, fragile.
The modern internet is tightly interwoven—and disruptions in one major provider can have cascading global effects.
The internet was designed as a distributed network, resilient by nature. Somewhere along the way, in the pursuit of optimization and cost-efficiency, we've created centralized chokepoints. Three companies—Amazon, Microsoft, and Google—control most cloud infrastructure. A handful of CDN providers like Cloudflare handle a massive percentage of web traffic.
This isn't necessarily bad. These companies are incredibly competent, with some of the best engineers in the world. But it does mean that when things go wrong, they go really wrong for a lot of people.
A Developer's Meditation
I want to end with something personal. As developers, we get caught up in the excitement of building new features, optimizing performance, and shipping products. We think about uptime in abstract terms—"five nines" of reliability sounds great until you realize that's still 5.26 minutes of downtime per year.
But incidents like this remind us that our work has real impact on real people. Someone couldn't get their work done because your service was down. Someone missed a meeting. Someone lost money. Someone's day got just a little bit worse because of a configuration file that grew too large halfway around the world.
It's humbling. And it should inform how we build.
The truth is, we can't prevent every outage. Systems will fail. Dependencies will break. Unexpected things will happen. But we can:
- Be transparent when things go wrong
- Build with resilience in mind from the start
- Test our failure modes
- Have plans for the worst-case scenarios
- Remember that behind every error message is a human being trying to get something done
The Silver Lining
If there's a positive takeaway from Tuesday's chaos, it's this: incidents like this force us to confront the reality of our infrastructure choices. They spark conversations about resilience, redundancy, and risk. They remind us that the internet, for all its magic, is ultimately a system built and maintained by humans—subject to human error, human decisions, and human consequences.
Companies will now re-evaluate their single-vendor strategies. Developers will add "Cloudflare outage scenarios" to their disaster recovery plans. And maybe, just maybe, the next time something like this happens, we'll be better prepared.
For the millions of people affected, it was a frustrating reminder of how fragile our digital infrastructure can be. As more of our work, entertainment, and daily life moves online, outages like this aren't just inconveniences—they're major disruptions that affect businesses and users worldwide.
Tuesday's Cloudflare outage lasted just over four hours. In that time, billions of dollars were lost, millions of people were frustrated, and the fragility of our interconnected digital world was laid bare for all to see.
The internet came back, of course. It always does. Services recovered, developers breathed sighs of relief, and life went on. But for those four hours, 20% of the internet held its breath—a stark reminder that the digital world we've built, for all its seeming permanence, is far more fragile than we'd like to believe.
So here's my challenge to you: go look at your architecture. Find your single points of failure. Build in redundancy. Plan for the worst. Because next time—and there will be a next time—it might be your users holding their breath, staring at an error message, wondering when things will come back online.
And trust me, you don't want to be on the other end of that conversation.
Update: Cloudflare has published a detailed post-mortem of the incident, which you can read on their blog. They've committed to hardening their systems against similar failures and implementing additional safeguards.
Have you been affected by this or similar outages? How do you handle infrastructure redundancy in your projects? Let's discuss in the comments below. 👇
Top comments (1)
Interesting post!
I was really curious what was that all about, since some of the websites I tried to access yesterday were down, including ChatGPT and others. And that happened around 15pm or so.
It is a very good idea to build with the worst case scenario in mind.