We're introducing Policies - a new way to encode organizational rules into incident.io to help you keep on top of your post-incident process.
After you've put out the immediate fire of an incident, it's often useful to create some follow-ups or run an incident debrief. Generally, it's up to individuals to ensure these processes happen, and if you're responding to an incident whilst juggling several other things, it's easy for things to slip under the rug.
That's why we're building policies - a way for you to define rules about how things should happen in the incident lifecycle and get notified if they aren't happening.
For example, you can define a rule like this:
Once a policy has been created, we'll monitor for any violations and inform you if they occur. You'll receive a Slack message, on your policy's configured deadline, detailing any new violations you're infringing on. Additionally, you can choose to receive scheduled reports that give you a list of all the policies currently being violated, so that you can keep on top of where you're not keeping up with your organization's rules.
Currently, you can add rules around follow-ups, but we're just getting started. Soon, we'll be adding the ability to define rules around incident debriefs (AKA post-mortems), so you can ensure the entire post-incident process goes to plan. If you've got ideas about what else you'd like to use policies for, we'd love to hear them so please drop us a message.
Policies are available in early access now, with a wider rollout coming in the next week or two. If you're keen to try it out, please get in touch.
It's not just policies we've been working on! We've also added the ability to mute both a single attachment and all messages from a specific type of attachment. If you're finding GitHub changes, or Zendesk Ticket updates noisy in your incident channels, we think you'll love this!
mode
field in the public API.