undefined | Better HN

0 pointssmcl3y ago0 comments

Step #3 is unfortunately often pointless given that often either:

1. the status page is unavailable too

2. the status page reports the service as green/available even though it's red/down (maybe it's still accessible to the service pinging its health status, maybe it's "accessible" but not actually functional, maybe the engineers were too busy fixing the problem to click the button to update the status page, maybe not updating the status lets them pretend they're within SLAs or KPIs)

0 comments

4 comments · 2 top-level

gibspaulding3y ago· 1 in thread

I suppose a static html page saying everything is fine hosted on the same infrastructure as your service would be an accurate indicator a good chunk of the time.

smclOP3y ago

Yeah it gives you a bit of confidence that the problem may not be something on your end. I don't think there's a perfect way to handle this, though.

pixl973y ago· 1 in thread

Most places don't have an automated status page because of the issues with automation showing outages when they don't exist. Someone manually goes and clicks something on the status page.

harrisi3y ago

This doesn't seem like a good reason. I can't imagine anyone checks githubstatus.com before accessing github.com. People check it after they have issues.

I assume it's more due to contracts, marketing, and denying responsibility.

j / k navigate · click thread line to collapse