3 ms·
...and there's a reason for that. Automations to update the status page are rarely acceptable, since the status page statuses have legal and financial implicati
by mostdataisnice 5y ago
...and there's a reason for that. Automations to update the status page are rarely acceptable, since the status page statuses have legal and financial implications. Therefore, the IM usually has to update it (or tell someone to update it). But, realistically, when you get paged, you first need to figure out what exactly is wrong and at least a vague idea of why. Then, you need to tell someone to update the page. Then, it gets updated.
The status page will always lag the outage. It's not a conspiracy.
- kazen44 5y agoAlso, in most teams, people who do external communication are different from those doing triage and troubleshooting.
- cheeze 5y agoYeah, but they are still people who are responding to a page, working on wording and getting it approved, and then updating. 20 minutes seems pretty reasonable to me.
- deathanatos 5y agoStatus pages should be driven that way, though. "legal and financial" implications and "It's not a conspiracy" is a poor excuse. Now, I'm on Azure, but it seems like from the comments the situations are similar. So, instead of an automatically updated status page that would help engineers do their jobs, we get a status page that isn't accurate, and customers have pull teeth to get a service credit where/when one is due. And it seems like you can have the cake and eat it too here: while IANAL, a footnote in the SLA or the status page that "this is a machine estimate and not reflective of what goes into the SLA" should do it, no?
- gowld 5y agoNot updating the status page, to avoid the legal and financial implications, is fraud -- taking money on false pretenses.
- yuliyp 5y agofraud? how? what guarantees do they make about timeliness of status updates on their services?