Alert Fatigue Calculator
Quantify analyst alert fatigue from queue depth, false-positive rate and shift utilisation, and estimate alerts left untouched.
About Alert Fatigue Calculator
The index blends three independent drivers of fatigue: whether the queue physically fits in the shift, how much of the work turns out to be pointless, and how frequently interruptions arrive. Load is halved before weighting so that 200% of capacity, not 100%, maxes out that component. Fatigue is measurable and it predicts missed intrusions: when the queue exceeds capacity, analysts triage by closing the cheapest alerts first, which is exactly the behaviour a low-and-slow attacker relies on.
Formulas
Alert Fatigue
Queue load = alerts per analyst × minutes per alert ÷ (shift hours × 60 × utilisation). Fatigue index = 0.45 × (load ÷ 2) + 0.35 × false-positive rate + 0.2 × scaled hourly arrival rate.
- load
- Required triage minutes as a percentage of usable shift minutes
- utilisation
- Fraction of the shift genuinely available for triage, typically 65–75%
- false-positive rate
- Share of alerts that close as benign
Unworked backlog
Unworked alerts = (required minutes − available minutes) ÷ minutes per alert, floored at zero.
- required minutes
- Triage minutes the incoming queue demands
- available minutes
- Usable triage minutes on the shift
Worked example
With the default values below, Alert Fatigue Calculator returns Alert Fatigue Index of 59.5. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Alerts arriving per shiftaccepts 0–100,000 alerts
- 240 alerts
- Analysts on the shiftaccepts 1–200 analysts
- 3 analysts
- Shift lengthaccepts 4–24 hours
- 8 hours
- Average minutes to triage an alertaccepts 0.5–240 minutes
- 7 minutes
- False-positive rate of the alert streamaccepts 0–100 %
- 75 %
- Alerts closed automatically by SOARaccepts 0–100 %
- 30 %
- Realistic triage utilisation of the shiftaccepts 10–100 %
- 70 %
Results
- Alert Fatigue Index
- 59.5 / 100
- Fatigue Risk Level
- High — triage quality is already degrading
- Queue Load vs Capacity
- 116.7%
- Alerts per Analyst per Hour
- 7.00 alerts/h
- Alerts Left Unworked per Shift
- 24 alerts
- Hours per Shift Spent on False Positives
- 4.90 hours
- Highest-Value Intervention
- Queue exceeds capacity — automate triage or add a seat before tuning anything else
Step by step
- 1Values used
- 2Alert Fatigue
- 3Unworked backlog
- 4Alert Fatigue Index= 59.5 / 100
- 5Fatigue Risk Level= High — triage quality is already degrading
- 6Queue Load vs Capacity= 116.7
- 7Alerts per Analyst per Hour= 7.00 alerts/h
- 8Alerts Left Unworked per Shift= 24 alerts
- 9Hours per Shift Spent on False Positives= 4.90 hours
Assumptions and limits
- The result is derived only from the 7 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
How is Alert Fatigue calculated?
Queue load = alerts per analyst × minutes per alert ÷ (shift hours × 60 × utilisation). Fatigue index = 0.45 × (load ÷ 2) + 0.35 × false-positive rate + 0.2 × scaled hourly arrival rate. The index blends three independent drivers of fatigue: whether the queue physically fits in the shift, how much of the work turns out to be pointless, and how frequently interruptions arrive. Load is halved before weighting so that 200% of capacity, not 100%, maxes out that component.
Why does Alert Fatigue matter?
Fatigue is measurable and it predicts missed intrusions: when the queue exceeds capacity, analysts triage by closing the cheapest alerts first, which is exactly the behaviour a low-and-slow attacker relies on.
What values do I need to enter?
This calculator takes 7 inputs: Alerts arriving per shift, Analysts on the shift, Shift length, Average minutes to triage an alert, False-positive rate of the alert stream, Alerts closed automatically by SOAR, Realistic triage utilisation of the shift. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.
Why cap utilisation below 100%?
No analyst triages for eight uninterrupted hours. Shift handover, case documentation, escalation calls, training and breaks reliably consume 25–35%, so a plan built on 100% utilisation is short-staffed by a third on day one.
Is a high false-positive rate always the problem?
Not always, but it is usually the cheapest thing to fix. If load is already above capacity, tuning alone will not save you — the arithmetic says you need automation or another seat as well.
