[traviscj]

On the other hand, makes it sound more likely to be a routing/reverse proxy issue instead of (say) a database issue. Those sound easier to deal with via a rollback vs something like "oops we dropped a critical index on the `messages` table".

[nyrikki]

With the length of the outage it seems more like a DB issue. And if this is still correct there look to be some fragile dependencies.

https://aws.amazon.com/solutions/case-studies/slack/

The API isn't even returning valid error codes.

  logging error: {"subtype":"api_call_error","message":"{\"ok\":false,\"error\":\"_http_error\",\"status\":0,\"retry_after\":null}","stack":"Error\n  

As you can hit their api servers I am betting some replication error in mysql but that is just a guess based on that case study.

I am betting they are saying 'connectivity' because that is the error the client logs.

[nyrikki]

It is back up for me, but now I am annoyed they can't follow specs at all.

For l

They ignore:

https://standards.freedesktop.org/basedir-spec/basedir-spec-...

And kitchen sink everything under the xdg config dir...

  ~$ ls .config/Slack/
  Cache/                Cookies-journal       
  dictionaries/         installation          Local 
  Storage/        
  Preferences           QuotaManager-journal  
  Cookies               databases/            GPUCache/             
  local-settings.json   logs/                 QuotaManager          
  storage/