By Stephen Whitworth3 min readArticle
Webster's Dictionary defines 'incident' as... just kidding, I'm not going to do that to you.
But really, in a world where things go wrong in organisations all of the time, what should our threshold be for defining an incident?
Unfortunately, there's no hard and fast rules that apply to every organisation. That said, here's a few questions you can use to diagnose whether the particular problem you're facing is an incident.
I hope it goes without saying, but incidents generally aren't a positive thing. Someone, or something, might be negatively impacted in a small or large way.
Incidents require some urgent action to be taken to investigate and remediate. They aren't deferrable in the same way as a normal task or a bug might be.
Incidents are generally not something one person can reasonably address end to end without involving anyone else.
Incidents often require other stakeholders to be kept in the loop with periodic updates on status. These might be your team, your board of directors, or your customers.
After an incident, you'll generally want to dig deeper to learn more, and see how you might prevent this in the future.
Sure you can! As with most things, context is everything, so read these as guidelines rather than hard and fast rules.
Organisations generally set their threshold for incidents too high, where only the most severe events are called incidents. We believe smaller incidents are extremely valuable, and there's significant value to be obtained by lowering your threshold for an incident. Smaller incidents are a great way to learn about the failure cases of systems and provide an opportunity for teams to practice response to larger issues.
When the cost of declaring an incident is low, there's little reason to avoid reporting and plenty of value to be extracted. Give it a go!
Start your free 14-day trial, no credit card necessary.