See Help > Incident Types for a guide on how to use incident types. Note that incident types are available for customers on our Pro and Enterprise plans.
We believe incident.io should be used across an organization, from SRE teams to Customer Success and People Ops.
Until now, the way you set up your incident response flows has relied on having one set of roles and fields for every incident, meaning you have to choose between having lots of irrelevant fields to cover every use-case, or not getting the full incident.io experience on some incidents.
That’s changing today with incident types, conditional fields and roles!
Incident Types
You can now configure a set of incident types, which you can think of templates for different types of incident.
Once enabled, all incidents will have a specific type, which you can use to tweak how the incident behaves to best suit the situation at hand.
Here at incident.io, we have our default type, Production, which applies to any customer facing issues we might be seeing. This is our broadest and most common type of incident - as Production is set as the default, we’ll pre-select this type in incident declaration forms, optimising for the most common path.
Using incident types means that we’ve been able to handle specific issues differently, all through choosing the right type. As an example, we’ve created a Security type for sensitive issues, which we configure to create private incidents by default.
Our Growth team have been using incident.io to track some experiments they’ve been running. We’ve been able to completely separate that flow from our engineering incidents with a new Experiment type. Now we can configure workflows, custom fields and roles without affecting each other.
What can I configure?
Incident types allow you to customise core incident configuration, and are supported across the product.
Custom Fields and Roles
Custom fields and roles can now be configured by incident type (and other conditions, too!).
This allows you to pick only the set of useful field and roles per type, reducing noise for your other incidents.
As an example, you can create engineering specific custom fields like Customers Affected and Impacted Product and have them appear only for relating types, such as Production incidents.
Roles can be configured similarly: our Security incidents have a Data Protection Officer role which is only necessary for that type of incident. The role would have appeared unnecessarily for all incidents types before, while it only appears when needed now.
Automation
Just like the configurable conditions for fields and roles, workflows and announcement rules also support incident types.
This can be really useful when building automation specific to a team or product area, as you can map configuration for those incidents against the specific incident type.
As an example, we’ve added some specific workflows and announcement rules to our own incident.io account:
- Announce new Experiment type incidents in our #growth slack channel
- Invite our Security Representative to channels for Security incidents
- Send reminders about our GDPR decision flow to Security slack channels
Severities
Severities can also be customised by incident type.
While we think it’s important that base severity levels and order will remain consistent across incident types, a Major incident means different things depending on the incident type, and should be customised to make this clear.
To help with this, you can now:
Override severity descriptions
Descriptions can be customised for each severity, specific for the incident type. A Major Security incident can be very different to a major app outage. This allows you to equip users with all the information they need to select the right severity for the situation.
Enable/disable severities
If a site outage is always Critical or Major, you can hide the Minor severity and get it out of your way. We didn’t want our Experiment incident type to be worrying us, so we hid all severities aside from minor here.
Privacy Settings
Incident types can enforce that all incidents are created in private channels. For Security or People Ops teams who need to carefully control access to the incident channel, this is a great way to ensure that confidentiality is the default.
It’s a fail safe way to make sure sensitive issues are dealt with appropriately, without humans having to remember to ensure privacy in the heat of an incident.
Insights
Insights can now be filtered by incident type, helping you understand performance for different types of response.
When you use incident.io across your business, it’s important you can focus in on the specific team or group to better understand your incidents.
Now you can filter insights by incident type, you can remove noise from Experiments or Security incidents in order to focus exclusively on Production, if that’s what you care about.
What’s next?
Incident types is already making our lives easier, which is exactly what you need in the high pressure environment when an incident is triggered.
We’d love to hear more and get inspired by the ways you are using it. Join our community and let us know your thoughts!
