It's super common and very useful for security systems to work like this. Instead of putting something in-line that might choke on a burst of traffic you put it off to the side and send it a firehose of packets it may or may not be able to handle. If it falls over, no problem.
Downdetector also doesn't have a motivation to lie.
I've yet to find a status page that wasn't lying about the actual status.
Also 97% up is bullshit for the 3% of people who are offline.
Saucelabs was doubly bad for this because I'm absolutely certain based on traces that they had some sort of demux bug where they would send events from their tunnel to the wrong job. I could see it in the logs that a test timeout was often the cause of an event firing that was looking for something that never happened, because the event immediately preceding it in the script was never fired. Which meant it was either dropped or went somewhere it shouldn't.
Then it stopped one day and there was nothing in their release notes about it. Lies compounded by further lies.
That's just the most memorable example I have. Stuff like this happens all the time and with many services it plays out the same. There's a perverse incentive not to be transparent about problems with the service, so the status pages play down the intensity of the situation.
Isnt downdetector just people reporting its down though? Its useful for sure but not actually hooking into any officialy API or anything. Great for when the status page also goes down but surely a lag time
I go to status pages to find out if 1) I’m crazy, 2) if our IT fucked up DNS.
Every service I’ve ever paid for or someone paid for on my behalf has gaslit me about their status page because it’s impolitic and bad for sales to update the page before you know what’s going on, just because some users are reporting issues.
So a third party doesn’t have to deal with VPs kneecapping the engineers’ access to the status page. Or some services can’t update the status page when the site is hard down because they are so obsessed with keeping it up that they have no mitigations when they are down.
I was the one at my biggest gig that had to push to get static 404 and 500 pages uploaded to S3 so we could show something for vanity URLs even if customer ID lookup was down. And then a customer noticed they hadn’t updated since they changed their contact info and I found the job was timing out without an alert or deployment failure for five months. Five. Months. The guy who wrote it had quit, and he didn’t follow my advice on copying a batch job I’d poured way too much effort into. The damned thing was timing out after 50 minutes. I followed my own advice and got it to 4.5 minutes. Almost all of that time delta was waiting for fanout calls, which were pounding the shit out of consumer facing services. 90% of the calls he was making didn’t need to be made.
Which I also think is overblown. The one thing that people can actually agree on is that dynamically setting sticker prices is bad, but nobody actually does this. There's less consensus on whether coupons (targeted or otherwise) are okay, even though they have the exact same effect (ie. $10 w/ $2 targeted coupon vs a Dynamic Price™ of $8).
Oh you're right. And if I enable "ask to keep changes when closing documents," it asks me if I want to "revert changes" when I quit, not "delete." That even survives a force-quit, so on-disk the file was autosaved, but it still remembers that the changes are in an uncommitted state.
Weird thing is with the setting disabled, quitting TextEdit with multiple new docs open asks if I want to "delete and quit," but Numbers only lets me "save and quit." Even if I press that, Numbers reopens those in a still-uncommitted state. So from all the CSVs I've opened in Numbers and messed with, I have literally 100 pending docs and can only get rid of them by clicking through every single one.
Are non-coders these days aware that they should use version control (and push their code to GitHub)? Or does their agent helpfully suggest setting up a GitHub repo?
I mean one thing frontier models are really good at is porting code with pretty low level of supervision. Provided there are enough fans porting packages from other ecosystems should not be a big challenge.
reply