From fan sites to the many blog posts about the subject, post-mortems are all the rage these days. Especially if you’re looking to do DevOps right.

It’s easy to see why post-mortems are useful as they provide an opportunity for reflection, learning and blameless discussion about what happened during an outage. Not only are they considered a requirement for those shops wanting to improve their internal process, it’s also become mandatory to have post-mortems so as to better communicate the event internally (to other parts of the company) and externally (to those customers potentially affected).

We have heard from many of our users that the ability to report on Incidents is a crucial one and that if only we had that one thing, their job (and lives) would be that much easier. Imagine that instead of sorting through all the different actions that let to problem resolution – email communications, chat messages, alerts from various systems and what you can remember of late-night phone calls- you could simply pull a report of the unified timeline of all activities surrounding the firefight from one place.

VictorOps now allows you to do just that with our first version of post-mortem reporting.

postmortem

Define a timeframe and receive the entire timeline for that period, broken into alerts, system actions and chat. Edit out lines that aren’t interesting and annotate with interesting points of resolution or notes that weren’t captured. Add a summary to the event and store in VictorOps.

postmortem2

You can print the report as a PDF and share it internally with other teams. Additionally, you can save reports for later comparison and analysis.

postmortem3

We are as excited about this feature as you are because we know the importance of reporting and being able to look back on what happened during an Incident.

You can read more specifics about post-mortem reporting in our Knowledge Base and remember…it’s not a failure if you learn something from it.