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?
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.
For web-application monitoring, we’ve [1] gone the approach of outside-in monitoring. There’s many approaches to monitoring and depending on your role in a team, you might care more about the individual health of each server, or the application as a whole, independent of its underlying (virtual) hardware.
For web applications for instance, we care about uptime & performance, tls certificates, dns changes, crawled broken links/mixed content & seo/lighthouse metrics.
Hey! Sorry to hijack the thread for the other, but just like the OP we've spent the last few years building Oh Dear and it does about 99% of what you're looking for. [1]
It has uptime, performance, SSL alerts and status pages. What's missing is the performance graphs on the status page, which is coming in a few months.
Simple Ops goes further than us by also measuring FCP though.
I hope everyone reads the post and not just the subject, which is misleading.
The tl;dr is: Microsoft will stop building the .exe's themselves, but PHP will still happily run on Windows. The community will most likely step in and build those binaries themselves.
For the common user, nothing much will likely change. They'll still be able to download the binaries straight of php.net, someone else will just have built them instead of Microsoft.
Here's a very quick way to check if you may be affected: this will check all certificates in the chain to see if they match the fingerprint of the to-be-revoked list.
Hard to say, as we don't have any insights into the client-side. But we can say that only ~2% of our clients had expiring root certificates in their chain in the last few weeks, so it's definitely a minority.
Since you don't control the clients in anyway, it might be that there are clients that haven't updated their local certificate stores in ages and don't yet trust the new root certificates.
For anyone interested in the code behind the halving, I had some fun dissecting the GetBlockSubsidy() function that takes care of halving & ending of block subsidy [1].
It continues to amaze me that I struggle to set up a 5-node database cluster without one going out-of-sync or split-braining every few weeks, yet the bitcoin network manages to keep thousands of miners in-sync. This has to be the best example of eventual consistency in a production network.