Lorin Hochstein 

Accidentally missing a scope for a query, resulting system behavior is "match everything", with disastrous consequences. another entry in a never-ending series.

(See also: missing WHERE clause in a SQL query)

EDIT: I got this wrong. It was not an unscoped query, it was a misinterpreted flag.

https://blog.cloudflare.com/cloudflare-outage-february-20-2026/

Cloudflare outage on February 20, 2026

Cloudflare suffered a service outage on February 20, 2026. A subset of customers who use Cloudflare’s Bring Your Own IP (BYOIP) service saw their routes to the Internet withdrawn via Border Gateway Protocol (BGP).

The Cloudflare Blog
Feb 22 at 1:58amWeb
Show threadLorin Hochstein Feb 22
I actually got the failure mode wrong: it was not an unscoped query, it was a misinterpreted flag. Wrote a quick blog post: https://surfingcomplexity.blog/2026/02/21/quick-takes-on-feb-20-cloudflare-outage/
Quick takes on Feb 20 Cloudflare outage

Cloudflare just posted a public write-up of an incident that they experienced on Feb. 20, 2026. While it was large enough for them to write it up like this, it looks like the impact is smaller than…

Surfing Complexity
Show threadPeter LudemannFeb 22
@norootcause There should also be mention of good human factors in API design, rather than something that mathematicians might like because of its "elegance". E.g., SQL update and delete should require a WHERE clause, even if it's WHERE TRUE. (Linux "rm" now has a check for "rm -r /").
Show threadLorin Hochstein Feb 23
@PeterLudemann I second this motion! (Even SELECT should require this, because sometimes actions are taken on the results of a query)
Show threadPeter LudemannFeb 23
@norootcause I've always had mixed feelings about "truthy" conversions (e.g., in Python, `if s` is interpreted as `if len(s)!=0`, which is ironic given #2 in the Zen of Python is "Explicit is better than implicit".
Show threadLorin Hochstein Feb 23
@PeterLudemann Along those lines, Go’s notion of default values is something that I’m not crazy about
Show threadPeter LudemannFeb 23
@norootcause OTOH, when a record has dozens of fields (e.g., protobuf/descriptor.proto), defaults are nice; especially when a field is added to a record and we don't want to modify every piece of code that uses it (it's often reasonable to change everything in a mono-repo but mono-repos are special cases - and protobufs were invented by a company that does have a mono-repo).
(I have seen other solutions - with their own pros and cons - to the problem of extending a record than the one that protobufs chose)