Yeah, it alternates loading telling me everything is fine, and just giving me a nginx 500 error. Seems that the status page should be hosted differently so it can be up even when other things are having issues.
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".
Returned for me when I was looking but took ~30 seconds to do so. They should host their status page on a separate domain and use something like CloudFlare in front of it to help with sudden spikes in traffic. Another alternative is to use Twitter / Facebook as the status page and let them deal with the traffic spikes, or just serve static HTML.
Pretty sure they provide an IRC interface, but almost certainly don't use IRC internally. There's almost no way they could support any of their fancier features using IRC. Reactions etc would be horrible to implement.
Yeah and the IRC interface has been getting worse recently. When they added the shared channels across teams they completely broke being able to '@' a user from the IRC gateway. Support said something along the lines of 'yup and we're not planning on fixing it'.
I'm expecting them to completely turn off the IRC gateway in the next year or two.
I'm sure they have fallbacks, but when their ecosystem (apparently) evolved around Slack, the fallbacks are less effective. Polling Jenkins to see when your job is done is more time consuming than receiving a Slack message.
If slack being down means you lose all insight into your build process and code management, you seriously need to introduce a secondary option immediately.
OP didn't say "all insight". There's a difference between being unable to see a stream of change events and not being able to see the current state of the system. The latter is completely unacceptable, whereas the former is just annoying.
And of course today's the first day we're using Slack for audience Q&A at a conference. 360 folks in a room now have to...raise their hands! So barbaric.
Then why did the Slack Status page have so many problems at the same time? Half the time loading it would give a 500 Internal Server Error, 45% of the time you'd get broken resources (images and/or CSS), and only 5% of loads would give you the full working page.
Maybe because it's under a lot more load during an outage and they haven't upsized the status page infrastructure to handle their ever increasing user base.
Reminder why your status page should be hosted in a very different way than your regular infrastructure... so you're way less likely to end up with issues on both at the same time.
I like how statuspage.io even has metastatuspage.com in case their primary domain/DNS/TLD has issues.
Reminder that you should check things first before commenting. Slack's status page is in a different infrastructure, somewhere using digital ocean while slack.com is using AWS.
Looks like it. When I first loaded HN 2 minutes after this outage started, the story was #2. Then I refreshed after 3 minutes and it wasn't on the front page at all. Used the search tool to find it and then upvoted.
If you see something like this and you think it's in error, you can let them know and they'll likely be able to respond more quickly. There's a contact link in the footer.
No, I'm not. In my experience the mods are quite responsive, and have explained site behavior on more than a few occasions. They've also adjusted flags and weights of submissions if they identify an issue.
Just a simple typo. The keys are pretty close together if your finger slips, and I imagine they have enough problems distracting them from proper spellchecking at the moment. :-)
130 comments
[ 1.9 ms ] story [ 182 ms ] threadhttps://aws.amazon.com/solutions/case-studies/slack/
The API isn't even returning valid error codes.
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.
For l
They ignore:
https://standards.freedesktop.org/basedir-spec/basedir-spec-...
And kitchen sink everything under the xdg config dir...
[citation needed]
I'm expecting them to completely turn off the IRC gateway in the next year or two.
The things we take for granted.
The slack.com IP's are owned by AWS, while status.slack.com resolves to some Digital Ocean IP's.
I like how statuspage.io even has metastatuspage.com in case their primary domain/DNS/TLD has issues.
I'm probably not making this any better by commenting, of course.
#jokingpeopleCOMEON
When your business motto is 'always on' - it's really, really bad to be 'off' - it's a deep transgression of the brand promise.
BB was structured poorly for this - they didn't grasp the concept of multiple nodes of redundancy very well. (Easy in hindsight).
But - we should all be impressed at how highly available Google, FB and some other brands are. That's impressive.
Given timeframe and upvotes, how is this not the top of HN?