I know it's been a little while since the original post, but thought I'd share anyway that what I’ve seen cause the most friction in setups like this isn’t missing integrations, but incident status and ownership being represented in several places at once.
When comms, incident tracking, and follow-up live in different tools, someone always ends up stitching together the real state by hand (this can be an issue both during incidents and during the review).
IMO, one pattern I've seen work well is making sure incidents live alongside the rest of the team’s operational work — stories, bugs, and follow-up actions — instead of multiple places. When incidents share the same place as normal work:
- Engineers don’t have to context-switch during response
- Ownership and status are immediately clear
- Post-incident action items live in the same place as regular stories & bugs
- Reporting and learning are more consistent
This may not mean reducing tools, but it does mean being explicit about which system owns incident status and follow-ups. Some are obvious single points of ownership like site24x7/you-APM that detect and pagerduty handles escalation--and IMO, one place that reflects the real state of the incident so teams aren’t reconciling it during or post incident.
You didn't mention what chat/other tools your team uses to coordinate solving incidents and communicating status to stakeholders - that is also a key tool to pay attention for incident management. Chatops is a bit of a buzzwords, but a few simple things can make huge difference in transparency to stakeholders (think customer-facing teams needing to know what's going on, etc).
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.