Live data from Hacker News

Cloudflare outage on November 18, 2025 post mortem

blog.cloudflare.com

51–60 of 953 posts

Re: Cloudflare outage on November 18, 2025 post mortem

#51

28M 500 errors/sec for several hours from a single provider. Must be a new record. No other time in history has one single company been responsible for so much commerce and traffic. I wonder what some outage analogs to the pre-internet ages would be.

Yes, all(most) eggs should not be in one basket. Perfect opportunity to setup a service that checks cloudflare then switches a site's DNS to akami as a backup.

Re: Cloudflare outage on November 18, 2025 post mortem

#53
post #31
post #21

Earlier quoted context omitted.

Probably because this case was something more akin to an assert than an error check.

You are saying this would not have happened in a C release build where asserts define to nothing? Wonder why these old grey beards chose to go with that.

> You are saying this would not have happened in a C release build where asserts define to nothing?

Afaik, Go and Java are the only languages that make you pause and explicitly deal with these exceptions.

Re: Cloudflare outage on November 18, 2025 post mortem

#54
> thread fl2_worker_thread panicked: called Result::unwrap() on an Err value

I don't use Rust, but a lot of Rust people say if it compiles it runs.

Well Rust won't save you from the usual programming mistake. Not blaming anyone at cloudflare here. I love Cloudflare and the awesome tools they put out.

end of day - let's pick languages | tech because of what we love to do. if you love Rust - pick it all day. I actually wanna try it for industrial robot stuff or small controllers etc.

there's no bad language - just occassional hiccups from us users who use those tools.

Re: Cloudflare outage on November 18, 2025 post mortem

#55
post #20

"Throwing us off and making us believe this might have been an attack was another apparent symptom we observed: Cloudflare’s status page went down. The status page is hosted completely off Cloudflare’s infrastructure with no dependencies on Cloudflare. While it turned out to be a coincidence, it led some of the team diagnosing the issue to believe that an attacker may be targeting both our systems as well as our stat…

it seems like a good chance that despite thinking their status page was completely independent of cloudfront, enough of the internet is dependent on cloudfront now that they're simply wrong about the status page's independence.

Re: Cloudflare outage on November 18, 2025 post mortem

#56
post #21

Why call .unwrap() in a function which returns Result ? For something so critical, why aren't you using lints to identify and ideally deny panic inducing code. This is one of the biggest strengths of using Rust in the first place for this problem domain.

Probably because this case was something more akin to an assert than an error check.

Oh absolutely, that's how it would have been treated.

Surely a unwrap_or_default() would have been a much better fit--if fetching features fails, continue processing with an empty set of rules vs stop world.

Re: Cloudflare outage on November 18, 2025 post mortem

#57
post #9

As always, kudos for releasing a post mortem in less than 24 hours after the outage, very few tech organisations are capable of doing this.

I'm curious about how their internal policies work such that they are allowed to publish a post mortem this quickly, and with this much transparency.

Any other large-ish company, there would be layers of "stakeholders" that will slow this process down. They will almost always never allow code to be published.

Re: Cloudflare outage on November 18, 2025 post mortem

#58
post #2

> a change to one of our database systems' permissions which caused the database to output multiple entries into a “feature file” used by our Bot Management system ... to keep [that] system up to date with ever changing threats > The software had a limit on the size of the feature file that was below its doubled size. That caused the software to fail A configuration error can cause internet-scale outages. What an era…

This wild `unwrap()` kinda took me aback as well. Someone really believed in themselves writing this. :)

They only recently rewrote their core in Rust (https://blog.cloudflare.com/20-percent-internet-upgrade/) -- given the newness of the system and things like "Over 100 engineers have worked on FL2, and we have over 130 modules" I won't be surprised for further similar incidents.

Re: Cloudflare outage on November 18, 2025 post mortem

#59

> This showed up to Internet users trying to access our customers' sites as an error page indicating a failure within Cloudflare's network. As a visitor to random web pages, I definitely appreciated this—much better than their completely false “checking the security of your connection” message. > The issue was not caused, directly or indirectly, by a cyber attack or malicious activity of any kind. Instead, it was tri…

Because we initially thought it was an attack. And then when we figured it out we didn’t have a way to insert a good file into the queue. And then we needed to reboot processes on (a lot) of machines worldwide to get them to flush their bad files.

Yeah, I can imagine that this insertion was some high-pressure job.

Re: Cloudflare outage on November 18, 2025 post mortem

#60
post #53
post #31

Earlier quoted context omitted.

You are saying this would not have happened in a C release build where asserts define to nothing? Wonder why these old grey beards chose to go with that.

> You are saying this would not have happened in a C release build where asserts define to nothing? Afaik, Go and Java are the only languages that make you pause and explicitly deal with these exceptions.

And rust, but they chose to panic on the error condition. Wild.
Post reply on HN