On a Tuesday at 2:14 PM, a major model provider began returning elevated error rates for a specific model endpoint. By 2:31 PM, a customer support platform that depended on that endpoint was producing degraded responses for twelve thousand concurrent users. By 3:05 PM, the support platform’s internal monitoring detected a quality drop based on user complaint volume — not system metrics, because the system was not returning errors. It was returning plausible but lower-quality responses with higher latency. The system had no fallback path, no model-level health check, and no way to detect that its primary model was producing worse output rather than failing outright.

This is a real scenario, reconstructed from patterns we have seen across multiple engagements. The details are composited, but every failure mode described here has occurred in production.

Timeline

The provider’s degradation was subtle. The model did not start returning errors. It started returning responses that were fifteen to twenty percent longer, with slightly lower relevance scores, and at three times normal latency. These are degradation signals, not failure signals. A system designed to detect failures would not notice them because the model was technically working.

At 2:14 PM, the provider’s status page updated to report “elevated latency” for the affected model. The support platform did not monitor the provider’s status page. It monitored its own infrastructure metrics: CPU, memory, network, request rate, error rate. All of these were green because the model was responding. The responses were just worse.

At 2:31 PM, users began noticing. The AI-generated support responses were less helpful, more verbose, and occasionally off-topic. Users who were accustomed to fast, concise responses were getting slow, meandering ones. Some users escalated to human agents. Others abandoned the chat. The users became the monitoring system because the actual monitoring system was not watching the right signals.

At 2:45 PM, the first internal report appeared in the support team’s Slack channel: “Is anyone else seeing weird AI responses?” The report was vague because the degradation was subtle. It was not obviously wrong. It was just less right. The support team could not articulate what was wrong because the responses were grammatically correct, on-topic, and contained relevant information. They were just not as good as usual.

At 3:05 PM, the support operations team correlated the reports with a spike in user escalations. They checked the AI system dashboard. Everything was green. The system was processing requests, returning responses, and meeting its SLA for uptime. The SLA did not cover response quality. It covered availability. The system was available. It was just not useful.

At 3:22 PM, an engineer checked the provider’s status page and found the latency advisory. They connected the timing: the degradation started within minutes of the provider’s advisory. The system had been producing lower-quality responses for over an hour before anyone identified the cause.

At 3:40 PM, the team manually switched to a fallback model. The fallback had not been tested with the production prompt configuration. It produced responses in a different format that broke the downstream rendering pipeline. Users saw malformed responses for another fifteen minutes while the team adapted the prompt configuration for the fallback model.

At 4:05 PM, the system was stable on the fallback model. The provider’s primary model recovered at 5:30 PM. The team switched back at 6:00 PM after verifying the recovery. Total incident duration: approximately two hours of degraded quality, plus fifteen minutes of broken responses during the failover.

What went wrong

The failures were architectural, not operational. The operations team responded well once they identified the problem. The architecture did not give them the signals they needed to identify it sooner.

No model health monitoring. The system monitored infrastructure health but not model health. Model health is different from infrastructure health. A model can be infrastructure-healthy — responding to requests, returning valid HTTP responses — while being model-unhealthy — producing worse outputs. Model health requires monitoring output characteristics: response length, latency percentile shifts, relevance score distributions, and token pattern changes. None of these were monitored.

The monitoring gap exists because model health metrics are harder to define than infrastructure metrics. CPU usage above ninety percent is clearly unhealthy. Response length increasing by fifteen percent might be a distribution shift in user queries or it might be model degradation. Distinguishing these requires baselining normal behavior and alerting on deviations, which is more complex than threshold-based infrastructure monitoring.

This complexity is the reason most teams skip model health monitoring. Infrastructure monitoring has established patterns: thresholds, alerts, dashboards. Model health monitoring requires domain-specific understanding of what normal model behavior looks like for your specific system and use case. There is no generic model health check that works across all systems. Each system needs its own baseline, and building that baseline takes effort that teams defer until after the first degradation incident.

No automatic failover. The system had a fallback model configured, but the failover was manual. The team had to identify the degradation, decide to fail over, and execute the switch. This took over ninety minutes. An automatic failover would have detected the degradation and switched to the fallback within minutes.

Automatic failover requires health checks that are specific to model behavior, not just infrastructure availability. The health check should evaluate model outputs against expected quality characteristics. If the outputs deviate beyond a threshold, the system should automatically route traffic to a fallback model.

The complexity is in defining the health check criteria. A simple latency threshold catches some cases. A response-length threshold catches others. A quality score from a judge model catches more cases but introduces its own latency and cost. The right combination depends on the system’s quality requirements and the cost of degradation going undetected. The cost of this incident — two hours of degraded service for twelve thousand users — was high enough that even an expensive judge-model health check would have been justified.

Untested failover path. When the team switched to the fallback model, the fallback had not been tested with the production prompt configuration. The prompt was tuned for the primary model’s behavior, and the fallback model interpreted it differently. This produced malformed responses for fifteen minutes while the team adapted the configuration.

A failover path that is not tested is not a failover path. It is a hope. Testing the failover path means running production prompts against the fallback model regularly — weekly or monthly — and verifying that the outputs meet quality standards. The test should be automated and included in the eval harness. If the fallback model fails the eval cases with the production prompt configuration, that is a known gap with a documented mitigation, not an unknown gap that surfaces during an incident.

The untested failover made the incident worse. The primary model was producing lower-quality responses. The failover to a model that broke the rendering pipeline produced actually broken responses. Users who had endured an hour of degraded quality then experienced fifteen minutes of broken quality. The failover, which should have improved the situation, temporarily made it worse. This is the worst possible outcome for a failover: it compounds the damage rather than containing it.

No provider status monitoring. The system did not monitor the provider’s status page. The provider published an advisory at 2:14 PM that explained the degradation. The system did not see it until 3:22 PM. A sixty-eight minute gap between the provider’s disclosure and the team’s awareness.

Provider status monitoring is a simple integration: poll the status page API and alert when an advisory is posted for a model or endpoint the system depends on. The integration is straightforward to build and provides early warning that can shorten detection time from over an hour to minutes. The integration is cheap, fast to build, and high-impact. It should be one of the first monitoring integrations a team builds when moving AI to production.

SLA did not cover quality. The system’s SLA covered uptime, not output quality. The system met its uptime SLA throughout the incident. It was available. It was just producing worse responses. Quality SLAs are harder to define and enforce than availability SLAs, but they are necessary for systems where output quality matters.

A quality SLA might define acceptable ranges for response length, latency, and relevance scores. If outputs fall outside these ranges for a sustained period, the SLA is breached and the failover should trigger. The SLA should be calibrated to the system’s quality requirements and should be monitored with the same rigor as availability. A system that violates quality SLA is functionally unavailable to users who need useful responses, even though the uptime SLA is met.

The cascading failures

The primary failure was model degradation. The cascading failures amplified the impact beyond what the primary failure would have caused alone.

The first cascade was user trust erosion. Users who received lower-quality responses for over an hour lost confidence in the AI system. Some escalated to human agents, increasing support costs. Others abandoned the interaction, potentially missing important information. The trust erosion persisted after the system recovered because users remembered the bad experience. Trust is built incrementally and destroyed quickly. One hour of degraded quality can undo weeks of positive interactions.

The second cascade was the failed failover. When the team switched to the fallback model, the untested configuration produced malformed responses. Users who had already experienced degraded responses now experienced broken responses. The failover, which should have improved the situation, temporarily made it worse. This is a compounding failure: the primary failure degrades trust, and the failed recovery erodes it further. Users begin to question whether the system will recover at all.

The third cascade was the slow recovery. The team switched back to the primary model at 6:00 PM, over ninety minutes after the provider recovered. They delayed the switch-back because they wanted to verify the recovery was stable. This caution was warranted given the failed failover, but it extended the period during which the system was running on a less-tested configuration. The team’s trust in the primary model had been damaged by the incident, and they needed time to rebuild it before switching back.

The fourth cascade was the response review burden. After the incident, the support operations team reviewed transcripts of interactions that occurred during the degradation window to identify responses that might have been wrong or misleading. This review took two analyst-days of effort and identified seventeen responses that contained inaccurate information. The downstream cost of those inaccurate responses — customer confusion, incorrect actions taken, follow-up support needed — is hard to quantify but real.

What the control layer should have caught

The seven control layers — model control, prompt operations, guardrails, budget governance, tool governance, observability, and evals — should have detected and contained this incident at multiple points.

Model control should have provided automatic failover. The model gateway should have health checks that detected the degradation and routed traffic to the fallback without manual intervention. The failover should have been tested as part of the release process.

Observability should have detected the quality shift. Monitoring output characteristics — response length, latency percentiles, token patterns — should have alerted the team within minutes of the degradation starting, not ninety minutes later.

Evals should have validated the failover path. The eval harness should include cases that run against both the primary and fallback models, verifying that both produce acceptable quality. If the fallback model does not pass the eval cases with the production prompt configuration, that should be a known gap with a documented mitigation.

Guardrails should have caught the malformed responses from the untested failover. Output validation should check that responses conform to the expected format before they reach users. If the fallback model produces a response that does not match the expected format, the guardrail should catch it and either request a retry or return a graceful fallback message.

Any one of these controls would have shortened the incident or contained its impact. The absence of all four is what allowed the degradation to last two hours and the failed failover to compound the damage.

Prevention measures

The incident produced five concrete prevention measures that address each architectural gap.

First, implement model health monitoring. Monitor output characteristics, not just infrastructure availability. Baseline normal behavior and alert on deviations. Use a combination of latency percentiles, response length distributions, and quality score sampling. The monitoring does not need to catch every degradation case. It needs to catch enough cases that the average detection time drops from hours to minutes.

Second, implement automatic failover with health-based routing. The model gateway should route traffic away from degraded models automatically. The failover should be triggered by model health metrics, not just infrastructure errors. The failover should be per-tenant where possible, so that a degradation affecting only certain types of queries does not trigger a full system failover.

Third, test the failover path regularly. Run production prompts against fallback models on a schedule. Verify that outputs meet quality standards. Include failover validation in the eval harness so that every release is verified against both primary and fallback paths. A failover path that passes last month’s test but not this month’s test is a failover path that will fail when you need it.

Fourth, integrate provider status monitoring. Poll provider status pages and alert when advisories are posted for endpoints the system depends on. Use this as an early warning signal that supplements internal model health monitoring. The integration takes hours to build and provides minutes of early warning during incidents that would otherwise take hours to detect.

Fifth, define quality SLAs alongside availability SLAs. Set acceptable ranges for output characteristics. Monitor them. Alert when they are breached. Make quality a first-class SLA dimension, not an afterthought. The quality SLA should be reviewed and adjusted as the system’s usage patterns and quality requirements evolve.

Decision rules

Treat model provider dependency as a risk when:

• The system depends on a single model or a single provider
• Output quality matters more than output availability
• The system serves users who will notice and react to quality degradation
• The failover path has never been tested in production conditions

The most important mitigation is tested automatic failover. A system with tested failover recovers from provider degradation in minutes. A system with untested or manual failover recovers in hours. The difference compounds over time: provider degradations are not rare events. They happen multiple times per year across major providers.

Design for provider degradation as a normal operational event, not an edge case. The system that treats provider reliability as a given is the system that produces an incident like this one. The system that treats provider degradation as an expected event is the system that recovers before users notice.

Ship it safely

If you’re hardening incident response and post-mortems for real users, our Fractional AI Reliability Partner covers it end to end. For a fast baseline across the seven control layers, take the AI Production Scorecard.