The Service Is Healthy but the Model Is Failing — Who Owns This Incident?

A Blind Spot in ML Operations

In production environments, we're accustomed to judging a service's health by latency, error rates, and uptime. But ML systems have a particularly frustrating failure mode: all infrastructure metrics are green, while the model's prediction quality quietly deteriorates.

A Reddit user posed exactly this question — when predictions clearly get worse but latency, error rates, and uptime all look fine, who in the team should lead the investigation? What seems like a minor process question actually cuts to the heart of blurry ownership in modern ML operations.

Why Model Incidents Are So Hard to Own

Traditional software incidents come with clear signals: service outages, API errors, response timeouts — an on-call engineer responds immediately. But degraded model quality is a "silent failure." It doesn't trigger any alerting thresholds, yet it can quietly damage business metrics for hours or even days.

What makes this worse is how responsibility gets fragmented. The original post describes a classic three-way standoff:

• The platform team checks the serving layer and infrastructure, confirming that deployments, resources, and routing are all fine;
• The ML team investigates the model itself and its features, looking for data distribution drift or feature degradation;
• The data team gets pulled in when there's suspicion that something changed in an upstream data pipeline.

Each team can independently complete their portion of the investigation and walk away with the same conclusion: "Nothing wrong on my end." That's precisely the problem — when everyone finishes their checks but no one is responsible for the final call on whether to keep the model running or roll it back.

Clear Division of Labor ≠ Clear Ownership

This is the most valuable insight in the original post: a clear division of labor does not equal clear accountability. The three teams run their legs of the relay race, but nobody holds the baton.

ML incident investigations are typically parallel and exploratory, with the root cause potentially hiding in any layer. While causality remains unclear, the business continues to absorb losses from bad predictions. What's truly needed in this moment isn't more investigators — it's a single, designated decision-maker who can answer:

Should the model keep running while we wait for a root cause, or should we roll back to the last stable version immediately to stop the bleeding first?

The author makes their position clear: they want one person to own that run/rollback decision, even as everyone else collaborates on finding the root cause. This is essentially importing the "Incident Commander" concept from traditional SRE into the ML domain.

---

The Incident Commander role originates from Google's SRE framework and is a cornerstone of large-scale production incident response. In traditional infrastructure incidents, the Incident Commander isn't necessarily the most technically skilled person — their job is to coordinate resources, drive decisions, and maintain communication cadence, keeping the response from devolving into "lots of meetings, few decisions." The mechanism works precisely because it explicitly separates "who is investigating" from "who makes the call."

Bringing this role into ML incident scenarios comes with a unique challenge: traditional incidents have a relatively clear definition of "recovery" (the service is available again), while the "recovery" standard for model quality incidents is often ambiguous. How much does prediction quality need to improve before we call it resolved? Who decides? These questions need to be agreed upon during process design — otherwise the Incident Commander will still face a decision with no criteria to anchor it.

---

The Core Debate: When Do You Hand Off?

What really sparked discussion in the original post is the question of handoffs — specifically when responsibility should transfer:

• Option A: The on-call engineer owns the incident end-to-end until it's fully resolved;
• Option B: Once the incident looks like a model quality issue, it gets transferred to the ML team.

Both approaches carry costs.

Keeping the on-call engineer in charge throughout maintains a single clear owner and prevents things from falling through the cracks — but the risk is that this engineer may lack the specialized skills to diagnose model quality issues, leading to a situation where someone is nominally responsible but practically lost.

Handing off to the ML team early puts the problem in the hands of people who understand it, but introduces a dangerous gap. The handoff itself can lose context, and the judgment that something "looks like a model problem" may simply be wrong — many incidents that initially seemed model-related turn out to be caused by data pipeline issues or serving configuration changes.

The author pointedly asks: What criteria should determine when to hand off? That decision standard itself is often the most conspicuously missing piece in team processes.

Actionable Directions

While the original post raises the question rather than answering it, a few directions emerge from industry practice:

1. Decouple decision authority from investigative authority. The on-call engineer or a designated Incident Commander retains the run/rollback decision regardless of which layer contains the root cause. Each team provides diagnostic conclusions — they don't make independent calls.

2. Use rollback capability to buy investigation breathing room. If a model can be rolled back quickly and reliably, the decision-maker can roll back first to stop the bleeding, converting the "run sick vs. roll back" dilemma into "roll back first, investigate at leisure" — dramatically reducing decision pressure.

3. Build observability for model quality. Silent failures are dangerous precisely because they lack signals. Prediction distribution monitoring, feature drift detection, and shadow traffic comparisons can ensure that "healthy service, broken model" is no longer something you only discover when a customer complains.

4. Define handoff triggers objectively, not by feel. Rather than the vague rule of "hand it to the ML team when it looks like a model problem," agree in advance on objective criteria — for example, a quality metric exceeding a threshold for N consecutive intervals, or all infrastructure checks passing cleanly, before formally transferring diagnostic lead. But decision authority stays with the commander.

---

Shadow traffic is a common model observability technique: real production requests are duplicated and sent to both old and new model versions simultaneously, with their prediction distributions compared — but only the production version's results are returned to users. This approach doesn't depend on labeled outcomes and can capture behavioral anomalies in a new model under real traffic in real time. It's an effective substitute for detecting silent degradation in scenarios where immediate ground truth isn't available.

Complementing this is prediction distribution monitoring, which tracks statistical properties of model outputs (mean, variance, quantile distributions) and fires alerts when significant shifts occur. The core challenge here is setting sensible alert thresholds: too sensitive and you get alert fatigue from false positives; too lenient and real degradation lurks undetected for too long.

Feature drift detection goes a step further, monitoring changes in the distribution of input features themselves — helping distinguish whether the root cause lies in the upstream data or the model.

---

Closing Thoughts

This Reddit question deserves serious attention because it reveals a genuine gap in MLOps maturity: we've built robust on-call and incident response systems for service availability, but we've rarely designed equally rigorous ownership mechanisms for model quality incidents.

When latency and error rates are all green, but the model is quietly making mistakes — who presses the rollback button? The answer to that question may reflect a team's engineering maturity more honestly than any monitoring dashboard ever could.