52 comments

[ 3.1 ms ] story [ 120 ms ] thread
Status page takes more than 30 seconds to load. Uhm.
Slack is generally very reliable. I wouldn't be surprised if this is the first "real world" load test its status page has ever had.
Developer productivity increases by an order of magnitude.
Except that I can't communicate with my dev team.
Yeah, maybe that's why their productivity has increased? :)
We're currently discussing architecture decisions.
Have you tried using email and/or a phone? These seem to work well for all other industries.
Don't be a jerk... he has a tool that he and his team likes, and he was using it for a real task. No need to be a jerk about it. Yes a phone would work, was that what he was using at the time? No.
Well he might have been using the Slack iOS or Android app so I think it's a bit premature to assume that he wasn't using a phone at the time.
Not for me! I was literally in the middle of working on a Slack integration. At least now I know I wasn't crazy when it seemed like only half the requests I made generated a bot message.
Somewhat related, but the status page states Uptime last 30 days: 99.99% but https://status.slack.com/calendar shows quite a few incidents in the past 30 days. Do only total "outages" count against the uptime?

FWIW, 0.01% of 30 days is 4 minutes 19 seconds.

The calendar also shows 100% uptime for June 2016 despite the big red outage indicator in today's box.

Perhaps the displayed uptime percentage is for the status page itself?

Ha! I opened HN after Slack went down. I guess I should get back to work.
If your status page is not 100% transparent, don't have a status page. If you can't stand behind the number, don't show the number.

As brown9-2 mentioned, 0.01% in the last 30 days is ~4 minutes, the outage I personally am experiencing with Slack is way more than that.

Too much friday beer?
You know you have major problems when the status page itself fails to load.

Is there a meta-status page?

Yup: https://metastatuspage.com/

Slack's status page is hosted by StatusPage, and it appears that the Slack client attempts to load the status page when it can't connect to Slack. So in effect, Slack is DDOS'ing their own status page.

I really did not expect anyone to actually come up with that. :)

They might want to do something about sending everyone over to that page.

We lost USENET to Reddit and Stack Overflow, and it feels like we're about to lose IRC to Slack.

The Internet dies a little every time someone starts a new Slack channel. I'm glad for the SPOF reminder.

Can you imagine how many copy-pasted certs, passwords, and CC# would be hoovered up were Slack compromised?

Don't blame the replacement. We lost USENET to spam and IRC to lack of innovation and poor UX.

I stopped using both USENET and IRC long before any of these alternatives appeared.

This is a very good point. Many people I know stopped using IRC quite a bit before they ever started using Slack.
The question I have is why aren't industry leaders contributing to these specs? Why isn't Slack sending RFCs to improve IRC?
Why would they want to? Improving IRC does nothing to benefit Slack.
There is no economic model to support free/open systems and standards. It's in nobody's best interest.
Slack's business is built on free/open standards, they don't exist without http and html. Asking them to contribute in their area of expertise is not asking a lot.
Not just that, none of the current web economy exists without linux and gnu and other free/libre software.
What benefit would it be to Slack to publish their protocols? Or to IRC to know about them? I think the chances are extremely slim that IRC could be improved by knowing how Slack works. Slack is not a technical marvel with mysterious underpinnings. It's a centralized chat service with a pretty interface, simple clients, and (the secret sauce that won them all the converts) seamless integrations with pretty much every other open or semi-open service out there.
IRC would benefit simply by having someone that's actually working to improve it. It doesn't matter if the improvements are superficial; humans are superficial, that stuff matter a lot.
Right. People are more than happy to use free, open source, standardized, distributed, self-owned software and services... when that software and those services offer the best solution for their needs. There's only so much ease of use and functionality people can be realistically expected to trade away.

Yeah, Slack is down... but the gains made from using it outweigh the pain of having to deal with the failure. Improve the less proprietary options to where this isn't true anymore and people will stop using the more proprietary options.

There are always trade-offs, and expecting people not to make them is unrealistic.

It's sad, I agree. But IRC is such a pain for most people to deal with it's never going to reach a mass audience in its current form. Whereas Slack is dead-simple easy to use and no one has trouble understanding how to use it. If you want to save IRC, then we need to make it usable by everyone.
Plus it's not like IRC itself isn't also a SPOF in a different way. I've had [private] servers go down, netsplits and connectivity issues on freenode effectively hindering communication...

And all of the things that people use to make IRC more bearable are problems in their own right. Imagine a vulnerability with the znc bouncer? Tons and tons of people compromised right there. irccloud down? Oops. and so on.

Can't we make it better? Can't we write an IRC protocol upgrade, server, and client that does the same thing that Slack beats IRC with?

Namely, archived chats and in-chat images.

> were Slack compromised? ... again
I really wish people would stop pretending Slack is just IRC with a brand name slapped on. It's so much better to use in every single way.

If you don't care about UX then you don't care about UX, but at least have the intellectual honesty to say it.

There is nothing about IRC which dictates what UX you have to use. Nothing was stopping the slack team with creating that client.
I don't think the parent comment is talking about the UX really.

But on the topic of UX and what are or are not losing, I will say that the UX of slack is not so good when it eats 2gb of memory all day and beachballs a modern day iMac quite badly if you have a channel with lots of fancy formatting.

I have written to slack about this and they wrote a polite response back acknowledging the issue. Really hope they do solve this soon (Despite the connectivity issues) because it's become unusable for my team lately. Supposedly according to slack it is compounded when you have multiple teams.

We have a team per client as we primarily do consulting, so now we have had to switch some teams over to another solution so that we can allow the teams that must be in slack to stay in slack.

So, while I think slack has the potential to be much better in every single way, days like today illustrate that it's an SPOF, and on days when it is available, I would not call the experience reliably good, not as reliably good as modern day IRC is, unfortunately. (and I don't say this lightly, i love things like in-line code blocks, @ notifying people, mobile clients, and more)

I care about UX but I care about my desired UX. I'm not a slack user but assuming it were to be offered to me I'd want a command-line client. If it didn't have that capability I'd pass.
If you don't care about UX then you don't care about UX, but at least have the intellectual honesty to say it.

I care about UX. What I don't care for is the idea the UX has become a distance multiplier when talking about differences in software.

Is anyone suggesting that Slack is literally just a client for the existing IRC protocol? No. They're suggesting that slack is just a particularly nice and popular iteration on IRC. You seem to have some impression that just because a slack feature isn't part of the IRC protocol, that it isn't a short evolutionary distance from IRC. Breed in some modern design conventions and use paradigms and you're pretty close. So it's not crazy to call slack IRC, it's a convenient shorthand for people who don't demand exacting terminology (and don't mind mentioning slack in the same breath as an icky ugly fixed with text-only app).

And that intellectual dishonesty comment is just a way to say a really shitty thing and fly it under dang's radar.

draw_down, could you tell me what you think the advantages are other than UX? I believe the bot integration may be better though I don't use it. I'm genuinely curious: I consider it simply Yet Another Chat System -- am I missing out on something?
Looks like this is a core router internet issue. I cannot access twitter.com, amazon.com, slack.com just to name a few.

However from a remote site I can access all sites. The sites aren't down - the internet routes are down.

Twitter shows a core router for telia went down last night "Telia lost a core backbone router in NY" https://twitter.com/ScottSwezey/status/741124806330978304

My tracerts to slack.com are dropping at a telia.net hop

Looking glass tool shows slack.com and amazon.com are down from the New York (111 8th Ave) router. - http://looking-glass.telia.net/

FWIW, all of my telia services out of NYC are fine (with no hiccups for days at least).
A ton of sites went down yesterday that were on the cloud-flare network due to them having an issue with one of their transit carriers.

Its crazy how the downtime of what seams like one edge network provider can damage so much of web access.