Mojah

There's a disclaimer at the top that anything below the intro was largely written by an LLM. That section is updated now

I'm keeping a list [1] of all the (possible) precautions one can take, ahead of the patches appearing in a few hours. Exploits are now circulating, according to Cloudflare's CTO, so _any_ mitigation is worth investigating

https://ma.ttias.be/php-cve-2026-109618-early-mitigation/

Reporting absolute instead of percentage values definitely makes it more human. But most of these reports & status pages are held up-to-date manually, by engineers, when incidents happen. I’d bet not even half of the real outages end up reported on there.

“It’s just a few minutes of downtime, nobody noticed, best not draw attention to ourselves by placing something on our status page”

Status pages should be tied into (external/simulated) monitoring to update in near real-time, without hiding incidents. Transparency is the only way. By reporting the _real_ hours of downtime, including the small stuff you think people didn’t notice.

Indeed, surprised me too - the majority of that is made up of "death by a thousand paper cuts", many 1 or 2 minute outages.

We’ve been seeing a surprising amount of leads come through this site, clearly the demand for a EU alternative is high.

Co-founder here, we'll be working on better ways to handle this over the coming days.

Interestingly, also noticing that websites that use Cloudflare Challenge (aka "I'm not a Robot") are also throwing exceptions with a message as "Please unblock challenges.cloudflare.com to proceed" - even though it's just responding with an HTTP/500.

Most companies prefer to fix any downtime before it's noticed, and sharing any details on a status page means admitting something went wrong.

There's plenty of status page solutions that tie in uptime monitoring with status updates, essentially providing a "if we get an alert, anyone can follow along through the status page" for near real-time updates. But, it means showing _all_ users that something went wrong, when maybe only a handful noticed it in the first place.

It's a flawed tactic to try and hide/dismiss any downtime (people will notice), but it's in our human nature to try and hide the bad things?

[1] ie https://ohdear.app/features/status-pages

Have you been able to try this with a `SELECT SQL_NO_CACHE * FROM ...` query?

If it's for local testing, you could try to cripple InnoDB as much as possible by just setting some absurdly low values, that would almost certainly mean no InnoDB caching is happening; https://gist.github.com/mattiasgeniar/87cd4a10bfcc788d81b51f...

Totally depends on the use case I suppose, we found that in our environment, we perform _a lot_ more SELECT's than we do UPDATE/DELETE/INSERT's.

And with some badly optimized SELECT's, the time MySQL had to spend on sorting results/reading from disk in an inefficient way made all our _write_ queries suffer.

By optimizing our SELECTs first, we freed up some CPU bandwidth (it seems?) that can be spent doing all the other work.