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.
The state of error handling in general is woeful, they do anything to avoid admitting they're at fault so the negative screenshots don't end up on social media.
Blame the user or just leave them at an infinite spinning circle of death.
I check the network tab and find the backend is actually returning a reasonable error but the frontend just hides it.
Most recent one was a form saying my email was already in use, when the actual backend error returned was that the password was too long.
I think the site (front-end) thinks you have blocked the domain through DNS or an extension; and thus suggests you unblock it. It is unthinkable that Cloudflare captchas could go down /s.
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.
That's good to hear. We have found some suspect SELECTs used in our client-facing API recently. Might be good to double-check that those are running efficiently and not hamstringing the writes.
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.
What do you mean you live by this? Do you mean you make a conscious choice to have passion instead of an interest? I don't think one can choose a passion. It's something you either have or don't.
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.
One point I don't see made often: in order to short or long any market, you need _initial_ capital too. This whole "ask 1 BTC to get 2 BTC" requires 0 initial upfront costs from the attacker.
It's a win/win situation, they can't lose. They've invested nothing in their scam to begin with.
Not just any initial capital, clean US dollars in a brokerage account under somebody's real name. You can't use BTC or rubles or drug money or whatever.
Update: our app is available again without Cloudflare, you'll be able to post updates to status pages smoothly again.