Hacker News Reader

Comment by scrose | Hacker News Reader

I find it amazing that we can be about an hour and a half into a service being completely unusable(ie. Slack telling me it 'cannot connect'), yet it's still marked as an 'incident' instead of an 'outage' in their own status page

View on HN

It's marked as an outage now.

and yet they're still proudly proclaiming: "Uptime for the current quarter: 100%"

Every time this kind of thing happens HNers love to grip about how the status pages aren't correct yet. It's so weird -- like the people freaking out about the outage are going to be updating their uptime trackers right now or something. Who cares? It'll be fixed later.

I think the point is that a "Status Page" should show the accurate, current status of the system. Not a place holder for "we'll fix it later". People look at a status page to know what's happening now.

I wasn't talking about the status page, I was talking about the uptime % tracker.

edit: oh, sorry, i did say 'status page' in the first part. But I kinda meant update % tracker like the parent.

Enterprise contracts have SLA's about uptime, so it's definitely relevant.

what's the point in a status page that only updates after the outage has been resolved?

It doesn't. The status page is currently showing information about the outage. And the 100% uptime number is probably still correct, since it's only been out for a couple of hours.

> And the 100% uptime number is probably still correct, since it's only been out for a couple of hours.

It's listed as "Uptime for the current quarter"; if they mean that as "calendar quarter", i.e. since the start of the year, then we aren't even 100 hours into the quarter so we should be well below 100% by now.

Fair point.

You might be correct, but why would anyone care about quarter-to-date as opposed to a rolling quarter ending now? The latter would mean that an outage of X duration will always reduce this statistic by the same amount regardless of how close the nearest calendar quarter boundary is, which seems like a superior quality for such a statistic to have.

That would be a completely fair metric to publish, but it doesn't look like what Slack is publishing. Of course, it's possible that it is and it's just phrased somewhat poorly.

Well, who consults a service's status page when it isn't down? During an outage is literally the only time a service status page has any function.

A status page that doesn't get updated during an outage is about as much use as a solar-powered flashlight (without built in power storage).

This is entirely in line with my experience dealing with outages. 85% of the time to fix consists of fielding requests for status updates.

It's like when people push the elevator button repeatedly if it's taking a while to arrive, only pushing the elevator button doesn't cause it to take even longer.

Interestingly their uptime for the quarter is still 100% despite a full-red dashboard. I wonder if that's something that is calculated only after an outage is resolved

Well until the issue is resolved you can't know how long you've been down for, so you can't actually update the uptime.

Why not? It could be updated second by second automatically if they wanted to.

Probably not a priority though.

Building out the infrastructure to automatically give real-time updates to your uptime figure sounds like a terrible use of company resources. Who knows how many person hours to spend on implementing and maintaining a feature that would remove maybe a few minutes of manual work from the incident post-mortem checklist, just for the sake of delighting people who need something else to look at for a workplace distraction now that Slack is down.

Well, now the outage is marked as resolved. And the uptime is still "100%".

Reply on news.ycombinator.com