On-Call AI Fatigue: When Your Pager Goes Off for an AI-Generated Incident

On-call has changed. Nobody asked if you wanted it to.

Before AI monitoring, on-call was straightforward in its misery: something broke, you fixed it, you went back to sleep. The incidents had names. The blast radius was visible. The fix usually lived in a file you had written six months ago.

AI-assisted on-call is different in ways that are hard to articulate until you have lived through a 2am page where the incident description reads like a hallucination, the suggested fix points to a service you have never touched, and the monitoring dashboard shows seventeen simultaneous anomalies that an AI model flagged as possibly related.

This is not on-call burnout. This is a specific, new form of fatigue that combines alert fatigue, cognitive overload, epistemic disorientation, and the peculiar frustration of being responsible for systems you do not fully understand, amplified by AI tooling that moves faster than your comprehension.

Engineers are naming it. They just do not have a vocabulary for it yet. That is what this page is for.

Five ways AI monitoring has changed on-call

1. More incidents. Fewer of them are real.

AI anomaly detection flags patterns humans would not have noticed and patterns humans would not have cared about. A latency spike that settles in forty seconds. A memory metric that crosses a threshold for eleven seconds. An error rate that doubles from 0.01% to 0.02%. AI catches these things aggressively, which means engineers receive more pages for things that would have self-resolved.

The result is a phenomenon engineers call alert fatigue with low signal: you wake up for something that was probably fine, resolve it in three minutes, and spend the next twenty minutes wondering if you missed something real buried in the noise.

2. AI-generated incidents that do not map to your mental model

Traditional monitoring alerts are rooted in human-authored thresholds and dashboards. You know what they measure. You know why they exist. AI-generated incidents come from statistical models that have found correlations you did not know existed. The incident may be technically accurate, something is genuinely anomalous, but the description is built from a pattern the AI found, not from a cause the engineer can intuit.

At 3am, working from a mental model you did not build is cognitively expensive in a way that regular on-call never was. You are not debugging a system. You are debugging an AI interpretation of a system.

3. AI-suggested fixes that feel like trusting a co-worker you have never met

Runbook automation tools now generate remediation suggestions in real time. Some of these are genuinely useful. Many require significant modification before they apply to your specific configuration, version, or dependency graph. A few are confidently wrong in ways that would make the situation worse.

The cognitive cost is not just evaluating the suggestion. It is evaluating the suggestion while simultaneously holding the production incident, the user's impact, and the manager's Slack thread. That is three simultaneous cognitive loads that AI has quietly added to every page.

4. The 24/7 AI observer changes team behavior

AI monitoring does not sleep. When your team knows that an AI is tracking every anomaly, every latency blip, every error rate movement, something changes in how they ship code. The psychological weight of the always-watching AI adds a layer of performance anxiety that did not exist when monitoring was something humans checked periodically.

Engineers report being more hesitant to deploy on Friday afternoons, more anxious during on-call handoffs, and more likely to over-document deployments just in case the AI flags something they will have to explain later.

5. Opaque ownership in AI-assisted systems

When an AI generates a configuration change, or suggests a migration, or auto-scales a service based on predicted load, and then something breaks, the question of ownership is genuinely unclear. Did the AI make a suggestion the engineer approved? Did the engineer miss something the AI was pointing at? The accountability gap in AI-assisted operations is real and creates a specific kind of anxiety that traditional on-call never had.

What this looks like in practice

These are composite stories from engineers who have described their AI on-call experiences. Names changed.

The cognitive stack of AI-assisted on-call

Regular on-call required holding a mental model of your system and using it to interpret alerts. AI-assisted on-call requires holding a mental model of your system, a mental model of your AI monitoring system, and the ability to rapidly identify which model applies to the current incident, while managing the social pressure of an active outage.

This is not a small addition. It is a qualitative change in cognitive load that compounds with every additional AI tool in your stack.

Signs you are experiencing on-call AI fatigue

Not every difficult on-call shift is AI fatigue. Here is how to tell if what you are experiencing is the specific compound form this page is about.

• You dread pages more because you do not trust what they will say. Regular on-call dread is about the incident. AI on-call dread includes the uncertainty of whether the incident description is accurate.
• You spend more time evaluating the AI suggestion than you would have spent just fixing it. This is the efficiency paradox: AI suggestions that take longer to evaluate than a direct fix would have taken.
• You feel less confident after AI-assisted incidents. The AI handled parts you did not understand, and you are less sure of the system's behavior as a result.
• You avoid looking at the AI monitoring dashboard when you are not on-call. Normal monitoring: you check it periodically. AI monitoring fatigue: you avoid it because seeing the noise is stressful.
• Your post-incident reviews are longer and less conclusive. When an AI was involved, the RCA takes longer because the AI's contribution is hard to isolate.
• You have started documenting AI behavior for future incidents. Engineers do this when the AI is unpredictable enough to require personal institutional knowledge.
• On-call rotation is affecting your decisions about what to build. If on-call is shaping your architectural choices, the tool is changing your engineering in ways you have not chosen.

What to do about it

Personal practices

Team-level changes

Organizational pressure points

• AI monitoring opt-in for new services: New services should not automatically inherit AI monitoring. Teams should choose to opt in once they understand the signal-to-noise ratio.
• Explicit on-call AI error budgets: If your AI tools generate false positives per week, that is a cost that should be tracked and discussed, not hidden in the monitoring dashboard.
• Post-AI-incident reviews: If an AI suggestion was part of an incident, the review should explicitly assess whether the AI involvement helped or hurt the response time.
• On-call rotations that include AI off weeks: Consider rotating engineers through periods where they are excluded from AI-assisted services, so skills and mental models stay fresh across the team.

Why on-call AI fatigue compounds with other AI fatigue

If you are already experiencing AI fatigue from your regular development work, the cognitive load of continuous AI tool use, the skill atrophy from AI-mediated debugging, the identity uncertainty of AI-assisted authorship, on-call AI fatigue does not just add to that. It multiplies it.

Here is why: the same cognitive resources that AI on-call depletes are the ones that AI tool use during the day has already partially exhausted. Attention residue from AI-assisted development work means you start on-call with a reduced capacity to hold complex system models. The AI suggestion that you evaluate at 2am is competing with the context switching you did all day with AI tools.

Engineers who describe their worst on-call AI experiences almost uniformly describe days that were already high AI-usage before the alert came in. The compound effect is real, and it is not being addressed by the teams deploying AI monitoring tools.

The answer is not to refuse AI monitoring. It is to deploy it with the same care you would apply to any tool that changes the cognitive demands of your engineering organization, with explicit thresholds, visible error rates, and ongoing calibration based on engineer feedback, not just detection metrics.

Frequently asked questions