Maybe I'm reading too much into it, but "We've received word that all workspaces are having troubles connecting to Slack." makes it sound like their internal monitoring didn't catch whatever is causing this. I was personally experiencing issues for about 20-30 minutes before the status update was posted.
Pretty much every time there's a slack outage it takes them a solid 20 minutes to update their status page. Several times I've emailed them 10 minutes into an outage (following "nobody at the office can reach slack, but their status page says smooth sailing, we should do more diagnostics in case it's office internet or something..."), then gotten a response 10 minutes later to the tune of "we're aware, we just updated our status page, go look at that". I think they consider updating their status page a PR problem, so they avoid if if the issue can be fixed in under X minutes.
Which also makes their uptime totals completely bogus.
It's interesting to me that the update messages are posted every 30 minutes from 1st notification until resolution. Judging by this and every other outage I assume this is automatic, and probably implemented to appease the people who are probably frustrated by the outage. https://status.slack.com/2018-06/142edcb9e52c7663
There is also zero information in those statuses, which kinda defeats the purpose. Might as well just have the status landing page with no details.
Hope Slack considers doing a post-mortem similar to Gitlab[1]. Sharing what they learned and giving customers context is appreciated. [1]: https://about.gitlab.com/2017/02/10/postmortem-of-database-o...
Yes, that way we can beat them up for years to come based on whatever mistake they made. It would be even better if they told us which employee made the mistake so we can incessantly mock that employee openly and publicly every time Slack is ever mentioned on HN. When GitHub was purchased by Microsoft, Gitlab came up quite a bit and we got to rehash that whole database outage over again many times over those few days…
I hope you don't work in aviation with that attitude!
In light of how Slack and other companies haven't been able to get a decent level of uptime, I have to say, the company known to make huge web applications that don't go down in shame every couple of months is probably Google. I can't remember the last time Gmail was down. It just works! If google is down, probably your internet is down. Their expertise and discipline in distributed applications is unrivaled. I'm gue…
And those SRE's? They use IRC.
they use IRC and they have a previously-communicated contact plan with redundant contact methods for when IRC is unavailable.
IRC had uptime in the scale of decades. Why are our 2018 solutions so fragile?
IRC netsplits quite a bit, breaking ongoing conversations until it’s recovered, to be fair.
Small ircds that you would run for a single team don't split because it's a single server.
Large networks can have the servers go up and down, and it's still not a big deal because of redundancy. DNS round-robin entries mean you don't even have to know the other servers on the network.
In 2018 netsplits caused by down links are fairly rare. If you wait six months you might see one.
You know how much of the community uses one messaging system when 15 minutes after it going down, it has over 40 points on the front page! This says a lot about how it's a single point of failure in modern company comms. It's even worrying to think about how some users probably have production-dependent (dare I postulate it) workflows in Slack that get crippled by its outage... ITT: Chat about decentralisation that w…
I worked at an open source company where they hosted their own IRC server. There are OSS alternatives to Slack and I wonder if that company has tried to adopt any of them. This all goes back to one basic fact: The Cloud is Someone Else's Computer(tm). If your hosted Confluence or Jira is down, you can go walk over to your IT team and they'll be like, "Yea we know. We broke something. We're working on it." If you're u…
I think it's inexcusable for a chat program to go down in 2018. * your hdd failed? Use a raid * your power went out? Use a UPS * your DNS went down? Use a fallback (slack2) * your whole datacenter flooded? Good thing you have multiple replicated cloud instances that seamlessly take over See, these are the issues that "the cloud" was supposed to solve. Not give us the same problems as before, just with a recurring bil…
>slack is the most trivial software you can think of This is like saying that food service at 30k feet in a passenger airline is trivial because all the server has to do is walk up and down a narrow aisle handing out food from a cart. Since "you see no reason this service can't be nearly as reliable as life support firmware", one of two things must be true: 1) You know something nobody else knows. In which case great…
3) slack will get their "chat as a service" monthly fee whether the service actually works or not, so why commit to higher levels of service? We can get our users acclimated to outages and then sell them "slack Premium, for Serious Business", charge an even higher fee, and get stupendously rich all over again. This is the "growth" that investors demand, no?