DevOps Philosophy and the Four Reasons PagerDuty Chose Not to Build a Native Chat Tool
Transparency and collaboration are at the core of DevOps philosophy, and ChatOps is an important aspect of both. ChatOps puts an entire team or organization’s work in one place – everyone’s actions, notifications and diagnoses happen in full view. A native PagerDuty chat client would be designed for use during incidents, and wouldn’t replace the chat client you use every day. Having two different chat records, which a native chat client would encourage, runs counter to the DevOps philosophy.
Valuable information should all be in one central location. Conversations about your outage should be in the same place as conversations about all aspects of your system, like information about your deployment, and who ran what script and when. It’s more helpful in the long run, and makes it easier to compose a post-mortem.
Incident responders shouldn’t be learning a new communication tool in the heat of an outage. There are more important things for them to be doing with their time in those critical minutes after receiving an incident, and they should be using the tool most familiar to them – the same chat client that they use to discuss their system as a whole and send each other cat photos.
Great partners already exist. PagerDuty is all about partnership, and there are already wonderful leaders in the space doing amazing things. PagerDuty is fully integrated with HipChat, Slack, and Flowdock. We like to leave building an effective, innovative, and ever-improving chat client to the experts, and instead focus on building the most reliable IT Operations Management platform on the planet.
Open source collaboration lets users customize with the chat client that works best for them. PagerDuty has a well-documented REST API, and we encourage our community to build open source tools between PagerDuty and existing chat clients. Amazing and useful things are being built all the time to be used with PagerDuty and the chat client of their choice.