Having multiple comms channels totally makes sense. I quoted “on premise” as most remote orgs are pretty much all cloud (though some may use colo)- which is really to say on hardware where a SaaS vendor doesn’t hold the keys. I can’t imagine how catastrophic a Slack hack would be for many orgs, and in that scenario you’re entirely dependent on their security and disclosure. It’s completely within their TOS to read your messages for various purposes, along with any apps that have been given access. That’s a pretty weak security posture if dealing with secret IP or other sensitive info. While nothing is guaranteed to be secure, limiting access to your team only seems like a smarter place to start for those who need privacy. Many companies really don’t, or at least accept a small level of risk.

In terms of losing systems that you need to access while troubleshooting systems issues, that can be a mess with self-hosted tools, but nobody is immune. When AWS had a cascading network failure at US -East-1, their team was unable to access their logging service which made triage incredibly difficult. That’s super rare, and unlikely to happen again for AWS in that manner, but outages can cripple any ops team. Runbooks are a great thing to copy offline!

As for documentation, it is quite easy to have it available offline.