Honest status page are a really really hard problem.
If your connector between your status monitor and the service breaks you'll have some subset of users panicking and causing problems (or asking for refunds for outages) when the service was up the entire time.
3rd party services are the only ones that you'll get a "more honest" but not always correct view of what the actual status is.
When an incident is declared, have someone tasked with determining customer impact. If the impact radius is greater than a handful of customers, declare a public incident. If customer communication is made a priority, then you can actually have a helpful status page.
Where I work, just about any non-false-alarm incident ends up on the status page in a timely manner. There's nothing stopping the likes of AWS from doing the same except for culture.
Exactly. It's the kind of thing where one person managing it and deciding whether to post updates is probably gonna work better than anything automated.
Well, maybe not at AWS scales though, if they have thousands of everything =/
I'm not talking about scraping, I'm talking about manual usage.
> You can easily check it manually.
You cannot. Twitter's site is plagued by redirect loops. If you work around those, these days /search just redirs to the login page. You can view single tweets, but there won't be any replies. (I have no idea if the site formerly known as Twitter is still rate-limiting views, or if they canned that.)
It is unusable if you're not actively logged in, and some of us have no desire to give away a phone number just to see AWS's true status.
If we as an industry can't think of something better (cough honest status pages cough) … can we at least transition these tweets to Mastodon.