* denial * acknowledgement of a limited scope * promises of transparency and openness * "we're working on it as hard as possible" * "all clear" announcement * carefully worded historical summary downplaying the event as much as possible
I am not saying that GitHub will do that but that is the common approach and it's very frustrating and does a huge disservice to all of us.
As an engineering team, you get held to the standards of whatever SaaS the executives you're talking to happen to know about or lightly use, and their perception is that those services NEVER go down or have issues. The poor and curated historical records don't help you make the case or describe what real SaaS uptime looks like.
Amazon is especially guilty of this. They only really admit issues when they've had a full-on, undeniable outage, and even then they curate the summary and impact very carefully.
* Submit comment on GH issue
* Receive inline error
* Reload page
* Receive 500 error
* Check status page (all green)
* Wait 30 seconds
* Check status page (issues was red)
* Wait < 5 minutes
* Check status page (more things are red)
* Wait another few minutes
* Reload GH issue page, it works
* Check status page all green
The only thing indicating no errors for today is the manually updated text summary at the bottom. The automated dashboard was, for me, extremely quick to update.
Also, you'll need an extra line break to create a multi-line list.