Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cloudflare outage on February 20, 2026

blog.cloudflare.com

Post reply on HN
Print view View original

31–40 of 135 posts

Re: Cloudflare outage on February 20, 2026

#32

Post by boarush »

jacquesm wrote: post #27
boarush wrote: post #2

While neither am I nor the company I work for directly impacted by this outage, I wonder how long can Cloudflare take these hits and keep apologizing for it. Truly appreciate them being transparent about it, but businesses care more about SLAs and uptime than the incident report.

Bluntly: they expended that credit a while ago. Those that can will move on. Those that can't have a real problem. As for your last sentence: Businesses really do care about the incident reports because they give good insight into whether they can trust the company going forward. Full transparency and a clear path to non-repetition due to process or software changes are called for. You be the judge of whether or not…

I might be looking at it differently, but aren't decisions over a certain provider of service being made by the management. Incident reports don't ever reach there in my experience.

Re: Cloudflare outage on February 20, 2026

#35

Post by blibble »

bretthoerner wrote: post #20
blibble wrote: post #12

is this blog post LLM generated? the explanation makes no sense: > Because the client is passing pending_delete with no value, the result of Query().Get(“pending_delete”) here will be an empty string (“”), so the API server interprets this as a request for all BYOIP prefixes instead of just those prefixes that were supposed to be removed. The system interpreted this as all returned prefixes being queued for deletion.…

> even if the client had passed a value it would have still done exactly the same thing, as the value of "v" (or anything from the request) is not used in that block If they passed in any value, they would have entered the block and returned early with the results of FetchPrefixesPendingDeletion. From the post: > this was implemented as part of a regularly running sub-task that checks for BYOIP prefixes that should b…

okay so the code which returned everything isn't there

actual explanation: the API server by default returns everything. the client attempted to make a request to return "pending_deletes", but as the request was malformed, the API instead went down the default path, which returned everything. then the client deleted everything.

makes sense now

but is that explanation is even worse

because that means the code path was never tested?

Re: Cloudflare outage on February 20, 2026

#36

Post by dakiol »

NinjaTrance wrote: post #8
Icathian wrote: post #5

Earlier quoted context omitted.

It is not. They went about 5 years without one of these, and had a handful over the last 6 months. They're really going to need to figure out what's going wrong and clean up shop.

Engineers have been vibe coding a lot recently...

No joke. In my company we "sabotaged" the AI initiative led by the CTO. We used LLMs to deliver features as requested by the CTO, but we introduced a couple of bugs here and there (intentionally). As a result, the quarter ended up with more time allocated to fix bugs and tons of customer claims. The CTO is now undoing his initiative. We all have now some time more to keep our jobs.
Post reply on HN