3 ms·
When I first got a 503, the status site was all green. I checked back for at least 4 minutes and it was still green. Finally it started to change. Is that sort
by foobarbecue 6y ago
When I first got a 503, the status site was all green. I checked back for at least 4 minutes and it was still green. Finally it started to change. Is that sort of lag normal?
- dmitrygr 6y agoIt is manually updated, by humans. Humans have high latency. It is not "agile" or "modern" or "hip" to have automated status testing/reporting. A human had to go and change that status page.
- taurath 6y agoWhen you're a public company the risk of your automated system saying something that invokes more fear than is necessary gets a lot higher.
- dmitrygr 6y agoYup, that is also why the status page now says things are "9/10 up" and for the first 20 minutes said "something is maybe slightly kinda wrong" nad not "outage". As if pretending nothing is wrong will make things right again.
- _jal 6y agoYep. I would be surprised to learn of non-infrastructure companies that wired their public outage notice directly to automated monitors with no human confirmation.
- foobarbecue 6y agoAha, I had figured it would be automatic. That does make sense, though.
- lykr0n 6y agoMaybe the status only changes when they've had 5 consecutive failures, and the probe only runs once a minute?
- manquer 6y agoThe primary value of a status page is SLA compliance and the financial implications of uptime. Near real time external alerting/reporting is probably not critical value prop for monitoring systems to sell, a 2 minute faster external notification is probably not going to make a new sale. Also the lag and human intervention is by design as there will be a lot of false positives as some error rates in these systems are expected, a very small percent of API calls will result in errors always like unhealthy instances etc. Unless the issue is substantially large it not in user(alert fatigue) or the business interest to declare it down.