One VP of Engineering at a 160-person healthcare SaaS company put it plainly in a recent industry interview: "Our on-call engineers get 200+ pages per week. Maybe 5 are real. The rest? Threshold noise, flapping alerts, things that auto-resolved. We've trained our team to ignore alerts, which is terrifying."
That last sentence is the whole problem. When the alert stream is mostly noise, engineers stop trusting it - and then a real P1 gets the same dismissive shrug as the thousandth false positive. A 2025 study by Splunk found that 73% of organisations experienced outages linked to ignored alerts. The conventional response is to redesign the rotation: swap weekly for fortnightly, add a secondary responder, split by timezone. Those are worth doing. But they don't fix the underlying signal quality, which is where the actual pain lives.
Why the schedule is not the root cause of on-call burnout
The 2025 SRE Report found that engineers spend a median of 30% of their week on operational work, up from 25% the year before.
Operational toil rose to 30% - the first increase in five years - even as many organisations were spending $1M+ on AI initiatives. The tooling investment is not translating into fewer human interruptions yet.
Alert fatigue is the root cause of most on-call problems. Teams that page on every anomaly create an environment where engineers stop trusting their alerts. When 80% of pages require no action, the remaining 20% that are real incidents get the same skeptical response - resulting in slower MTTR, not faster.
The Google SRE Workbook recommends no more than 2-3 actionable incidents per shift as a sustainable baseline. Consistently above that, and the rotation model may be the problem, not the team. The problem is that if your team is consistently seeing 8-10 per shift, you don't have an on-call problem - you have an alerting problem.
The cost compounds beyond productivity. Between 65 and 83% of DevOps professionals experience burnout, with on-call duties as a primary factor.
Teams facing burnout see reduced productivity, higher error rates, and ultimately higher turnover. Losing seasoned SREs doesn't just cost morale - it costs months of recruiting and onboarding, plus institutional knowledge that walks out the door.
What AI is actually changing in on-call workflows
The most useful thing AI is doing in on-call operations right now is not scheduling - it's grouping. PagerDuty's AIOps excels at noise reduction by grouping related alerts into a single incident. However, the subsequent investigation - digging into logs and metrics to find the "why" - remains a manual process for the on-call engineer.
That gap between noise reduction and root-cause explanation is where the newer generation of tools is working. Incident.io's AI SRE cuts downtime by starting investigations instantly - instead of spending 15 minutes context-switching between Datadog, GitHub, and Slack to correlate a deployment with an error spike, the AI surfaces that correlation in 30 seconds.
Teams using AI-powered incident management platforms report reducing MTTR by 17.8% on average, with leading implementations achieving 30-70% reductions, and a 2025 SolarWinds report found AI-powered platforms save an average of 4.87 hours per incident.
PagerDuty's Spring 2026 product release went further, shipping a set of distinct agents rather than a single AI layer. Their Shift Agent detects and resolves on-call scheduling conflicts directly from Slack, helping to ensure toil-free coverage.
The SRE Agent detects, triages, and diagnoses incidents based on historical incident data and observability logs, then performs approved remediation and retains past incidents and user actions to improve future responses. These are meaningful additions - but they are still layered onto a human-in-the-loop model where someone gets paged first and the AI helps them respond. The engineer is still the one being woken up. They're still the one who needs to formulate the right query to get useful suggestions from the AI.
The rotation design fixes that still require human judgment
Every on-call program has at least one person who absorbs disproportionate load - the senior engineer who gets called when others can't resolve something. This is not a people problem. It is a rotation design problem. When load is not measured and distributed deliberately, it concentrates.
AI systems can track that drift. AI scheduling systems can track overtime hours per worker, surface inequitable patterns, and rotate backfill offers across qualified, available workers before defaulting to the same five names. Measuring load distribution - total pages per shift, after-hours interruptions, incidents per engineer per month - is the data foundation that makes rotation adjustments legible rather than political.
A well-designed rotation starts with the right team size. The minimum sustainable rotation requires at least four to five engineers - fewer than that, and on-call frequency becomes burdensome.
Expecting full sprint velocity plus on-call responsibility is unreasonable. A common approach is assigning 50% of normal capacity during on-call weeks. Neither AI scheduling nor noise-reduction tooling changes that arithmetic.
Engineers who wake up at 3 AM without documented procedures are forced to wing it under pressure, leading to longer mean time to resolution, more stress, and decisions made without context. A teammate like Beagle, watching a live incident thread in Slack, can surface the last postmortem for the same service and pull the relevant runbook section into the channel - which is a smaller thing than autonomous resolution, but it shortens the gap between "paged" and "knows what to try first."
Where the honest limit is
The most useful framing right now: AI has gotten good at reducing the number of incidents that need a human at all, and at giving humans faster context when they do need to respond. Industry data consistently shows that engineering teams spend 30-40% of their working hours on operational toil - alert triage, incident investigation, and repetitive remediation tasks that could be automated. For a 10-person SRE team at an average fully-loaded cost of $250K per engineer, that's $625,000-$1M per year spent on toil alone.
Noise means alerts that are duplicates, low-value, flapping, or false positives. The goal is fewer pages, faster triage, and less alert fatigue - without losing signal. That is what the better tools are delivering in narrow conditions. What they are not delivering yet is a rotation that feels fundamentally different to the engineers inside it - because the structural problems (team size, alert discipline, sprint protection during on-call weeks) are management decisions, not configuration settings.
The VP of Engineering's 200-pages-a-week problem is solvable. The solve starts with an alert audit, not an AI contract. Once the noise floor is lower, the scheduling and triage automation actually pays off. Buying AI tooling first and skipping the hygiene work is the error most teams make.