I'm looking for better ways to handle post-incident documentation in our team. We typically experience about 10-12 incidents each month, and the process for documenting them is quite cumbersome. Usually, the on-call person is responsible for writing up what happened, but it often takes them 3-4 hours as they juggle between monitoring dashboards, chat logs, and deployment history.
More often than not, the documentation ends up late or doesn't happen at all, and by day three, details start to fade, making the documentation shallow. Does anyone have a process or tools that could improve this situation? Have teams just accepted that this task is a time sink?
1 Answer
It sounds like you're dealing with a hefty number of incidents! One thing I'd suggest is to start documenting right when a major incident is declared. My team tackles it by having one person focus on documentation while another troubleshoots. We share notes and actions in real time, then clean everything up after the incident. It saves a lot of time and ensures we capture important details.
That's a smart way to handle it! But do you find it tough to get someone to take on the "documenter" role during late-night incidents? How much time does it take to polish up everything after the fact?