The conversation about on-call burnout in security teams almost always frames it the same way: too many alerts, too many false positives, too much noise. The solution, in this framing, is better alert tuning. Reduce the volume, improve the signal-to-noise ratio, and the burnout goes away.
This is not wrong. Alert volume matters. But it is not the whole story, and for a lot of teams it is not even the main story.
What on-call engineers actually describe as exhausting
When you talk to security engineers who have left on-call rotations or burned out on them, the complaint is not usually "there were too many alerts." It is more specific than that. It is: "every alert required the same setup work before I could even start investigating." It is: "I spent the first twenty minutes of every incident doing the same three things I had done the last time, and the time before that."
That repetitive setup work is context-gathering: figuring out which asset was affected, pulling the relevant logs, understanding what normal looked like for that asset, checking whether anyone else had seen this pattern recently. None of it is the actual incident response work. All of it is precondition work that has to happen before the real judgment calls begin.
This is what I mean by context fatigue. It is not the number of alerts that is exhausting. It is the fact that each alert requires the same cognitive ramp-up, from zero context to enough context to act, before anything useful happens. Do that ten times a week and you are not just tired. You are specifically tired of being reset to zero every time.
The important difference between alert fatigue and context fatigue
Alert fatigue is a signal quality problem. The fix is tuning your detection rules, raising thresholds, improving the precision of your SIEM queries. This is real work and it is worth doing. Reducing false positives directly reduces the number of times the on-call is woken up for nothing.
Context fatigue is a workflow problem. Even if you have excellent alert fidelity and every alert represents a real signal worth investigating, each one still arrives as an isolated event without context. The on-call still has to go find out what the affected asset is, what it connects to, what normal looks like for it, and whether there has been any related activity in the past few hours.
Tuning your detection rules does not fix context fatigue. You can reduce alert volume to one alert per week, and that one alert will still require twenty minutes of setup before the engineer can do anything with it.
The 3am cognitive budget problem
Context-gathering is not neutral work. It consumes the same cognitive resources as the investigation itself, but produces no diagnostic output. When an engineer spends twenty minutes gathering context before an incident, they start the actual investigation already depleted. The judgment calls they need to make at that point, is this a false positive? is this lateral movement or a misconfigured service? should I isolate now or wait for more evidence? require clear thinking, and clear thinking is exactly what the context-gathering phase has been spending down.
At 3am, this effect is amplified. The cognitive starting point is lower. The cost of each setup step is higher. And the probability of making a poor judgment call increases as the setup phase drags on.
This is not about the skill of the engineer. It is a structural property of how incident response usually works: context arrives after the alert, not with it. The engineer is the mechanism by which context gets assembled, rather than the environment providing it automatically.
What actually reduces context fatigue
The solution is not alert tuning. The solution is changing who, or what, does the context assembly.
When Parachute receives an alert, it immediately begins the context work that the on-call would otherwise have to do manually: it identifies the affected asset from the alert metadata, pulls the relevant logs for that asset, checks the asset's recent activity, and in many cases has already taken the first containment action before the on-call has been fully notified. By the time the engineer opens PagerDuty, the context is already assembled and waiting.
The on-call's first action is now to read a brief, not to build one. That is a fundamentally different cognitive entry point. The judgment work starts immediately rather than after a setup phase.
What this does not solve
Automating context assembly does not fix alert volume. If your detection rules are generating a hundred low-fidelity alerts per day, automating the context-gathering for each one means you have a hundred automated context packages instead of a hundred manual setup tasks. You have not reduced the on-call load; you have just moved the human intervention to a later stage.
Context automation is most valuable when the alert volume is already reasonably well-tuned. It compounds alert quality: high-fidelity alerts plus automatic context means the on-call arrives at actionable information quickly. Low-fidelity alerts plus automatic context means you have automated a waste of time.
Do the alert tuning work first. Then ask whether the alerts that remain still require a manual setup phase before the engineer can act. If they do, that is the context fatigue problem, and that is where automation earns its keep.
A note on retention
Context fatigue is one of the more consistent predictors of on-call burnout in security roles, based on the teams we have talked with. The people who leave on-call rotations are often not leaving because the incidents are hard. They are leaving because the same trivial work happens before every incident, regardless of how hard or easy the incident turns out to be.
Reducing that trivial work is a meaningful quality-of-life improvement for the people doing the job. It is also a signal to the engineer that the team takes their time seriously. That combination, less repetition plus visible respect for cognitive load, is more retention-relevant than most of the other things teams try.
