Alerts. It’s so easy for them to pile up. One moment, you’re looking at a handful of alerts. A few hours — or maybe even minutes — later, you’re looking at a mountain. How do you manage them and keep your responders from being completely overwhelmed?

These are hugely important questions. If your alert management system is flooded with noise and response teams are in a permanent state of alert fatigue, you may as well not even have an IT alert management system in the first place. Excessive noise and alert fatigue completely reduce the effectiveness of the alert management system.

Apply Filtering: Alerts to Incidents

In many ways, the key to streamlining your alert management system lies in a rapid and accurate method for consolidating related alerts into incidents and determining incident priority. Sorting incidents by urgency provides an automatic filter for most noise and it provides you with a reasonable approximation of what needs immediate attention, and what can wait. Also keep in mind that not every alert needs an incident or a response — suppressing non-actionable alerts further cuts down the noise and lets you focus on what matters.

You will probably be able to automate at least part of the sorting process (for example, by source and keywords), although it is likely that some (and perhaps a considerable amount) of it will require monitoring and intervention by response team members operating in the dispatcher role. Whatever method you use, however, the basic criteria will remain the same.

Most priority schemes follow the ITIL incident prioritization guidelines, or something similar. One of the key elements of the ITIL guidelines is that incident priority is based on two closely related factors: impact and urgency. In this post, we’ll take a closer look at both of those factors, and how they interact.

Determine Incident Impact

Impact is generally based on the scope of an incident’s effects — how many departments, users, or key services are affected. It can be relatively easy to automate at least some elements of the impact determination process. A large number of near-simultaneous reports that a specific service is unavailable, for example, may be a good indication of a high-impact incident, while a report of a problem from a single user, unaccompanied by any similar reports, is more likely to indicate a low-impact incident. For many IT departments, the guidelines for determining incident impact might look something like this:

• High impact:
  • A critical system is down.
  • One or more departments is affected.
  • A significant number of staff members are not able to perform their functions.
  • The incident affects a large number of customers.
  • The incident has the potential for major financial loss or damage to the organization’s reputation.
  • Other criteria, depending on the function of the organization and the affected systems, could include such things as threat to public safety, potential loss of life, or major property damage.
• Moderate impact:
  • Some staff members or customers are affected.
  • None of the services lost are critical.
  • Financial loss and damage to the organization’s reputation are possible, but limited in scope.
  • There is no threat to life, public safety, or physical property.
• Low impact:
  • Only a small number of users are affected.
  • No critical services are involved, and there is little or no potential for financial loss or loss of reputation.

Incident Urgency

It is not always easy to draw a strict distinction between incident impact and incident urgency, but for the most part, urgency in this context can be defined as how quickly a problem will begin to have an effect on the system. The failure of a payroll system may have a high impact, for example, but if it occurs at the beginning of a pay cycle, it is likely to be less urgent than the loss of a customer relations database which is put to heavy use on a daily basis.

• High urgency:
  • A service which is critical for day-to-day operations is unavailable.
  • The incident’s sphere of impact is expanding rapidly, or quick action may make it possible to limit its scope.
  • Time-sensitive work or customer actions are affected.
  • The incident affects high-status individuals or organizations (i.e., upper management or major clients).
• Low urgency:
  • Affected services are optional and used infrequently.
  • The effects of the incident appear to be stable.
  • Important or time-sensitive work is not affected.

Note that for both impact and urgency, meeting a single criterion (rather than all or a majority of criteria) for a category is generally sufficient. Incidents should be placed in the highest category for which they qualify.

Priority = Impact + Urgency

At this point, it should be pretty easy to see that priority is a direct function of both impact and urgency. Regardless of the alert management and incident dispatching processes you put into place, should they route based on criteria for determining priority, you’ll be able to hush a considerable amount of alert noise, and low-impact, low-urgency events will naturally sink to the low end of your priority list. This will allow your incident response teams to concentrate on the kind of high-impact, high-priority incidents which genuinely require the most attention — with very little distraction or alert fatigue.

To learn more about how to aggregate, classify, and suppress events to manage what matters, check out PagerDuty’s alert triage and event rules engine. You can also easily classify incidents based on your organization’s custom definitions of priority.

And that mountain of alerts? By focusing on what’s actionable and urgent — especially with the help of a solution like PagerDuty — you may just find that it isn’t there anymore!