Live data from Hacker News

Slack was down

status.slack.com

231–240 of 243 posts

Re: Slack was down

#231
post #60

Earlier quoted context omitted.

We don't pay for 100% uptime. We pay so that we don't have to put the time into operating a service. That way we have more of our time to focus on our business problems.

If you're willing to tolerate these kinds of outages, you don't have to spend much time operating a service, either.

The problem is the time spent talking to the users.

If I own this service, it's not enough that I just reboot the service when it goes down. I'm now responsible for when it's slow, when it doesn't do what someone expects, when the user doesn't understand what the service does correctly, when someone forgets their password, etc.

"Foo as a Service" is as much (or more) about transferring the customer service responsibilities for dealing with the end users as it is for delivering the service itself.

Re: Slack was down

#232
post #227

Earlier quoted context omitted.

The Zulip server uses very little CPU, but the RAM is important. (I work on Zulip.) Here's what the docs say, for reference (excerpt of https://zulip.readthedocs.io/en/latest/production/maintain-s... ): > For an organization with 100+ users, it’s important to have more than 4GB of RAM on the system. Zulip will install on a system with 2GB of RAM, but with less than 3.5GB of RAM, it will run its queue processors multi…

Well my question is why they consume so much memory/CPU? What makes these services so different from earlier chat systems? Are these users continuously doing video chat with each other or keep sockets open? For simple text chat, 4GB of RAM seems absurdly high, considering how irc was able to handle thousands of users 3 decades ago.

IRC is essentially stateless. The server doesn't remember what messages people have sent; so it can't tell you what was said last night when you come online in the morning, or what was just said in some channel you weren't previously listening to. That work gets pushed out to clients, and to add-on services.

The IRC server also doesn't store images or any other kind of file people want to show each other. There are lots of good practical reasons to want to share images in a conversation (e.g., screenshots), plus of course silly GIFs. That work also gets pushed out to add-on services.

When people say here that Slack or Zulip etc. are a much better user experience than IRC, I think those two things -- message history, and images -- are major reasons for that.

Message history means a database that gets big, and images mean a lot of data too. There's a large working set of both of those that you want fast access to. That means providing adequate RAM.

Re: Slack was down

#233
post #231

Earlier quoted context omitted.

If you're willing to tolerate these kinds of outages, you don't have to spend much time operating a service, either.

The problem is the time spent talking to the users . If I own this service, it's not enough that I just reboot the service when it goes down. I'm now responsible for when it's slow, when it doesn't do what someone expects, when the user doesn't understand what the service does correctly, when someone forgets their password, etc. "Foo as a Service" is as much (or more) about transferring the customer service responsib…

While that's generally true, chat is pretty straightforward and it's not that hard to set up a IRC or Matrix server and direct users to download and configure a client. Besides, when Slack goes down all the time, your IT guys are going to have to deal with users complaining anyway.

Re: Slack was down

#234
post #160

Earlier quoted context omitted.

It takes much longer to listen to an audio recording than it does to read a sentence. And in certain cases, compose one.

Agree, because the audio is richer. A slight pause, a 'hmmmm', a chuckle, can infer the statement as a question, or at least give a hint as how confident the statement is, instead of a proclamation. Otherwise, without inflection, every sentence can read as a definitive statement. Zero nuance, and we end up with places like Twitter. It's awful for discourse.

Nuance is great and all but when you're deal with a lot of information you want to convey information as clearly and unambiguously as possible. Audio just doesn't have the information bandwidth that writing does.

Re: Slack was down

#235
post #231

Earlier quoted context omitted.

The problem is the time spent talking to the users . If I own this service, it's not enough that I just reboot the service when it goes down. I'm now responsible for when it's slow, when it doesn't do what someone expects, when the user doesn't understand what the service does correctly, when someone forgets their password, etc. "Foo as a Service" is as much (or more) about transferring the customer service responsib…

While that's generally true, chat is pretty straightforward and it's not that hard to set up a IRC or Matrix server and direct users to download and configure a client. Besides, when Slack goes down all the time, your IT guys are going to have to deal with users complaining anyway.

> your IT guys are going to have to deal with users complaining anyway

Except that IT can say "Complain to Slack or complain to your manager that we shouldn't use Slack. Don't complain to us."

This is remarkably valuable--doubly so if your management is stupid and regards IT as a cost center instead of as something useful.

> chat is pretty straightforward and it's not that hard to set up a IRC or Matrix server and direct users to download and configure a client.

Is that true? Take Single-Sign On, for example. That's remarkably non-trivial for IRC. I'm skeptical it's any easier for Matrix/Slack/etc.

Re: Slack was down

#237
post #160

Earlier quoted context omitted.

Agree, because the audio is richer. A slight pause, a 'hmmmm', a chuckle, can infer the statement as a question, or at least give a hint as how confident the statement is, instead of a proclamation. Otherwise, without inflection, every sentence can read as a definitive statement. Zero nuance, and we end up with places like Twitter. It's awful for discourse.

Nuance is great and all but when you're deal with a lot of information you want to convey information as clearly and unambiguously as possible. Audio just doesn't have the information bandwidth that writing does.

How so?

What can be said with writing can also be said with speech.

But with speech, you also have verbal queues, pauses, tone, inflection, that implies so much more.

Re: Slack was down

#238
post #27

" Some workspaces might be experiencing issues with messages sending and loading." (emphasis mine) Is that marketing-speak to lessen the loss of trust?

I think it was actually true- I am signed in to two workspaces -- one paid plan and one free -- and only the latter has been unavailable so far.

For me it was actually the opposite. I was thinking that only paid workspaces were impacted, which would be mildly funny

Re: Slack was down

#239
post #237

Earlier quoted context omitted.

Nuance is great and all but when you're deal with a lot of information you want to convey information as clearly and unambiguously as possible. Audio just doesn't have the information bandwidth that writing does.

How so? What can be said with writing can also be said with speech. But with speech, you also have verbal queues, pauses, tone, inflection, that implies so much more.

Because you can read a sentence much quicker than you can listen to an audio clip of that same sentence. The inflections don't convey as much unambiguous information as actual words. Was that sigh because someone was tired, frustrated, or just needed to take a breath?

Re: Slack was down

#240
post #170

Earlier quoted context omitted.

I suggest https://downforeveryoneorjustme.com/ , slack its own self, or https://www.isitdownrightnow.com/ or https://hosting.review/check-if-website-is-down/ or https://www.isitwp.com/uptime-checker/ . No need to fill this site with three or four postings with non-substantial comments.

Sites like that just check if the URL is reachable. They don't have any way of testing for API issues.

Right. HN does neither.
Post reply on HN