Run incidents without leaving Slack
Tailored to your organization for smarter incident management
Confident, autonomous teams guided by automations
Learn from insights to improve your resilience
Build customer trust even during downtime
Connect everything in your organization
Streamlined incident management for complex companies
Run incidents without leaving Slack
Tailored to your organization for smarter incident management
Confident, autonomous teams guided by automations
Learn from insights to improve your resilience
Build customer trust even during downtime
Connect everything in your organization
Streamlined incident management for complex companies
Summary templates can be used to encourage responders to provide relevant and consistent information across all of your incidents. This further helps to reduce the cognitive load on responders and lowers the barrier for newcomers to respond to incidents.
They can be defined for each individual incident type, as types such as “Operations” and “Security” are likely to have very different defaults.
You can go to Settings → Incident Types → Summary template to set this up now.
The terminology for postmortems and debriefs isn’t yet standardized across the industry. We’ve optimized for familiarity by using the most standard terminology, but we know that others prefer different terms to best describe them.
If you use a different word to represent a debrief meeting, you can now change the default. We'll then use your preferred name across our entire platform. Additionally, you can configure the default title and description we use when pre-filling a debrief event.
This is now available in Settings → Debriefs → Customise debrief name.
We recently released a new look for workflows, for a much more intuitive experience. We have now rolled out these improvements across the rest of our platform. Some of the highlights from these improvements are:
We’ve swapped out red and gray for pink and cyan, and added orange alongside a few extra icons. This prevents any confusion, as red could be mistakenly interpreted as broken and grey interpreted as inactive.
We now expose any errors that have been encountered when creating a Jira issue for an incident. This makes it clear why that failure has happened, as well as a pointer as to how it happened. This gives you more observability and control, reducing confusion, and improving the time to fix any problems.