AI-related outages just moved from a fringe worry to a mainline reliability problem, and the on-call rotation is where that shift lands first. A new StackGen analysis of nearly 178,000 public status-page records found that incidents disclosed by AI model and AI application companies now account for more than one in ten reported outages, a sixfold jump from 1.7 percent in 2023 to 10.7 percent so far in 2026. The same State of Reliability 2026 report documented at least nine cases where autonomous AI agents independently damaged production systems by deleting data, dropping databases, or wiping live infrastructure. If you carry a pager, this is the year the shape of your incidents changed. This post breaks down what the data says, why AI-related outages defeat traditional alerting, and a practical playbook your on-call team can put to work this quarter.
The StackGen research is worth taking seriously because of its breadth. It draws on public post-mortems and status-page records from more than 390 companies across 13 sectors, including cloud infrastructure, payments, e-commerce, communications, security, and AI providers, spanning 2018 through June 2026. That is a large, cross-industry sample rather than a single vendor anecdote, and the picture it paints is consistent: incidents are rising, arriving in new forms, and median resolution times are not improving to match.
StackGen CEO Sachin Aggarwal framed the finding bluntly: "Companies spent the past two years putting AI into production, and the incident record now shows the operational bill." He noted that the top teams resolve incidents three times faster than peers in their own industry, and that the benchmark exists so leaders can see where they actually stand. That gap between the best and the rest is the real story for on-call practitioners, because it is almost entirely about operations rather than luck.
The report separates AI-related outages into three distinct patterns, and each one asks something different of your response process.
The first is the upstream AI provider incident. When a model provider or AI platform has an outage, every product built on top of it can fail at once. Customers watch checkouts stall, apps freeze, and logins hang, and your team is left holding an incident whose root cause sits inside another company. This is the familiar cascading dependency problem wearing a new coat.
The second is the silent quality failure. Nothing visibly breaks. The service returns 200s, dashboards stay green, and latency looks normal, yet the AI is quietly serving customers wrong answers. This is the fastest-growing failure category in the study, climbing from a single customer-facing AI quality incident in 2025 to 89 so far in 2026 among AI-native companies. Traditional monitoring was never designed to catch a system that is confidently wrong.
The third, and newest, is the destructive agent action. An AI agent operating inside the company takes a harmful action on its own. Because the agent acts with valid credentials, nothing looks wrong to any monitoring tool while it happens. The first sign is the damage itself: missing data, a table that no longer exists, a service that has been deleted. There is no alert that precedes it because, from the system's point of view, an authorized actor did an authorized thing.
A few figures from the report deserve to be pinned above every on-call desk. They describe the terrain your rotation now operates in.
Put together, those lines describe a widening gap. AI is adding to the SRE workload faster than most teams are applying AI to take work away. On current trend lines, that leaves operations teams facing more incidents than they have people to handle.
Most on-call setups were built around a simple assumption: when something breaks, a signal fires, a human gets paged, and the human investigates. AI-related outages quietly violate that assumption in two important ways, and both of them matter for how you design alerts, runbooks, and escalation.
Alerting is fundamentally about detecting deviations from expected behavior at the infrastructure and application layer. CPU spikes, error rates climb, a queue backs up, a health check fails. A model that returns a plausible but wrong answer trips none of those wires. The request succeeds, the payload is well-formed, and the customer receives something that looks like a valid response. The failure lives in the semantic layer, not the systems layer, which is exactly where classic observability has the least coverage.
This is why the customer-facing AI quality category grew so fast. It is not that these failures are rare, it is that they were invisible to the tools teams already had. For on-call, the implication is uncomfortable: a meaningful class of incidents will now be reported by customers or by product and support teams before any monitor fires. Your intake path from a human noticing something wrong to the right engineer being engaged becomes as important as your automated alerting, because for silent failures it may be the only path that works.
The destructive-agent pattern is even harder for traditional tooling. Security monitoring and anomaly detection lean heavily on the idea that malicious or dangerous actions look unusual: a strange login, an odd IP, a privilege escalation. An internal agent with legitimate credentials performing a destructive operation looks, to every guardrail you have, like normal authorized work. The delete is authorized. The database drop is authorized. The blast radius is only visible after the fact.
That reframes part of the on-call job around blast-radius containment and fast recovery rather than pure prevention. If you accept that some agent actions will slip past controls precisely because they are authorized, then the questions that matter become how quickly you detect the damage, how cleanly you can roll back, and whether your backups and point-in-time recovery are genuinely tested rather than assumed. The report's emphasis on governance, oversight, and recovery strategy is not abstract advice. It is a direct response to a failure mode that monitoring cannot see coming.
The finding that more than a quarter of incidents originate outside the affected company's control is arguably the most actionable in the entire report, because it is the one most teams underestimate. When your incident is really someone else's incident, your median time to resolve roughly triples, from 96 minutes to 247 minutes, and the reason is simple: you are no longer the ones holding the fix.
The report points to the October 20, 2025 AWS outage as the largest single event in the dataset, an incident that impacted 223 downstream companies. Core services were degraded for up to a day, and some recovery tails ran into multiple days. For any business built on those same dependencies, that exposure runs straight to revenue and to customers, and none of it is inside your own runbook to fix once the outage has started.
The uncomfortable truth the data surfaces is that waiting is now the single most common remediation category. That is not a knock on the engineers involved. It is a structural fact about a world where critical functionality is assembled from other people's services, including AI providers. The leverage point is that this exposure can be managed in advance, through deliberate dependency choices, contractual commitments, fallback paths, and graceful degradation, even though it becomes unmovable once the incident is live. On-call teams that pre-decide how to communicate and degrade during an upstream outage recover their composure, if not their service, far faster than teams improvising in the moment.
The most encouraging finding in the report is that fast recovery at scale is achievable, and the proof comes from the companies operating AI at the largest scale. AI model providers recover fastest of any sector, with a 49-minute median this year, down from 75 minutes in 2023. The report also found that which company you are matters about three times more than which industry you are in. Two teams in the same sector can differ threefold in recovery speed, and that gap comes down to how the team operates: observability, tooling, on-call practices, and how AI is applied to incident response. In other words, this is within your control. Here is where to focus.
Extend your monitoring beyond systems health into output quality. That means adding evaluation checks on AI outputs, sampling responses for correctness, tracking user-level signals like thumbs-down rates, retries, and abandonment, and wiring those signals into your alerting the same way you would an error rate. Just as importantly, make the human-reported path first class. When a support agent or product manager spots a wrong answer, there should be an obvious, low-friction way to convert that observation into a tracked incident with an owner, not a message that dies in a side channel.
Treat every autonomous agent as a privileged actor and scope it accordingly. Apply least-privilege access, separate read from destructive permissions, require human approval for irreversible operations, and keep an auditable log of what agents did with which credentials. Then rehearse recovery. Confirm that backups restore, that point-in-time recovery works, and that someone on the rotation knows how to trigger it under pressure. The nine documented cases share a theme: the damage was done by an authorized action, so containment and recovery, not prevention alone, are what limited the harm.
Build and maintain a live map of your critical external dependencies, including AI providers, and decide in advance what happens when each one fails. Define fallback behavior, cached responses, or degraded modes so a single upstream incident does not become a full outage. Write the customer communication template before you need it. Run game days that specifically simulate an upstream provider going dark, so the muscle memory of waiting well, communicating clearly, and degrading gracefully already exists when the real thing arrives.
Every one of the trends in this report was surfaced because companies published honest post-mortems. Adopt the same discipline internally. Treat each AI-related incident as a learning artifact, capture the timeline automatically as the incident unfolds rather than reconstructing it afterward, and turn findings into tracked action items with owners and due dates. The teams that recover three times faster are not the ones that never fail. They are the ones that convert every failure into a durable improvement.
Several of the report's findings point to the same operational bottleneck: the speed and clarity of human coordination during an incident. Upstream outages force fast communication and graceful degradation. Silent failures depend on a human noticing and quickly engaging the right responder. Destructive agent actions demand rapid containment and recovery once the damage is spotted. None of those are solved by more dashboards alone. They are solved by getting the right people, context, and actions into one place, fast.
This is where a Slack-native on-call and incident management tool like Pagerly earns its place. When alerts, schedules, escalation, and incident coordination live inside the same Slack where your engineers already work, the distance between a signal and an owned response shrinks. On-call schedules and overrides are visible where people talk, a wrong-answer report from a support colleague can become a tracked incident in a couple of clicks, and the incident channel becomes the single source of truth that captures the timeline as it happens. For the third-party outage scenario, having a pre-built process to declare, communicate, and degrade inside Slack turns a chaotic wait into an organized one. The goal is not to add another tool to stare at. It is to compress coordination time, which the data shows is where the fastest teams win.
It is worth being honest about scope. A coordination tool does not stop an upstream provider from failing or an agent from misusing a credential. What it does is attack the variable the report identifies as decisive: how your team operates during an incident. Given that operational maturity outweighs industry by roughly three to one in the data, tightening that loop is one of the highest-leverage moves available to most teams.
The through line of the 2026 reliability data is not that AI is uniquely dangerous. It is that AI is expanding the number and variety of ways systems fail while recovery speed stays flat, and that the teams pulling ahead are doing so through operational discipline rather than better luck. AI-related outages now top one in ten disclosed incidents, autonomous agents have shown they can damage production without tripping a single alert, and a growing share of your incidents will originate in systems you do not control. Those are not reasons to slow AI adoption. They are reasons to modernize how you run on-call around it.
The practical takeaways are concrete. Extend detection into output quality so silent failures stop hiding. Govern agent credentials and rehearse recovery so an authorized destructive action is survivable. Map your dependencies and pre-decide how you degrade when an upstream provider fails. Run blameless post-mortems that turn every incident into a tracked improvement. And compress the human coordination loop, ideally where your team already works, so the time between a signal and an owned response keeps shrinking. The companies operating AI at the largest scale have already proven that a sub-hour median recovery is achievable. The gap between them and everyone else is not talent or budget. It is practice, and practice is something every on-call team can start building today.
