Monitoring What Raises No Error
In one line: latency, traffic, errors and saturation tell you the service is running, and none of them tell you it is right — so an AI system needs a monitoring layer that classic systems do not.
The gap
The four golden signals were designed for systems that fail by stopping. An AI system fails by continuing.
Every AI system needs both layers. The infrastructure layer tells you the service is alive; the quality layer tells you it is still doing its job. Naming that split explicitly is a good way to open the monitoring part of an answer.
Four tiers, ordered by how fast they tell you
The useful frame is latency of signal, because it decides what you can act on during an incident versus what you learn next quarter.
| Tier | Signal | Latency | Needs labels |
|---|---|---|---|
| 1 · Infrastructure | Latency, error rate, saturation, feature-fetch failures | Seconds | No |
| 2 · Input and output shape | Feature distributions, null rates, score histogram, flag rate | Minutes | No |
| 3 · Proxy behaviour | Click rate, reformulation, dwell, escalation, override rate | Hours | No |
| 4 · True quality | Accuracy against delayed labels or human review | Days to months | Yes |
Tier 2 is the one candidates skip and the one that catches most real incidents. It is cheap — a histogram of scores and a null-rate check per feature — and it catches the most common production failure in machine learning systems, which is not model decay at all but an upstream pipeline breaking.
A feature that starts returning nulls does not error. The model happily treats null as a value, the score distribution shifts, and quality degrades. Tier 1 sees nothing. Tier 4 will notice in a month. Tier 2 sees it within minutes.
Tier 3 deserves more credit than it gets
Proxy behaviour is available in hours and correlates with quality well enough to act on. The trick is choosing signals that mean failure rather than success:
- Query reformulation — the user searched again immediately, so the first attempt failed
- Escalation to a human — the support bot did not resolve it
- Override rate — the human reviewer disagreed with the model's decision
- Immediate dismissal — shown, then closed within a second
- Retry or regenerate — the user asked for a different answer
Each is a user telling you the system failed, without anyone labelling anything. Building the product so it collects these signals is a design decision, and mentioning that makes the point that observability is architecture rather than instrumentation added later.
Aggregates hide the failure you care about
A model can improve on average while collapsing for a group, and the aggregate cannot show you.
This is the same survivorship dynamic from the metrics lesson, now as a monitoring requirement. The fix is to decide the segments in advance and report every quality metric sliced by them.
A reasonable default set: new versus established users, each major locale, each device class, each major content or product category, and the tail of low-activity users. If you only pick one, pick new users — they are the segment with the least data, the worst performance, and the most influence on growth.
What an on-call engineer can actually do
A monitoring design that produces an alert nobody can act on has not helped. So the design should include the responses, and there are essentially four.
| Response | When it applies | What it needs to already exist |
|---|---|---|
| Roll back the model | The regression started at a deploy | Previous version deployable in one command, and version stamped on every prediction |
| Fall back to a simpler policy | The model is unreliable but the product must work | A non-ML fallback — popularity, rules, last-known-good — that is kept warm and tested |
| Disable a feature | One upstream pipeline broke | The model to tolerate a missing feature rather than crash or silently degrade |
| Shed to human review | Decisions are costly and volume is survivable | A review queue with capacity, and a policy for what to do while it drains |
The middle two are the ones candidates rarely mention and interviewers reward.
A non-ML fallback is the most valuable thing on the list. Popularity-based recommendations are much worse than a good model and enormously better than an outage, and the fallback has to be exercised regularly or it will not work when needed. A fallback that has not run in six months is a hypothesis.
Tolerating a missing feature has to be designed in. The default behaviour — imputing a zero or a mean — is a silent quality regression. Explicitly modelling a feature as absent, and monitoring how often it is, turns a silent failure into a visible one.
Log enough to explain a decision later
The last requirement is one that only becomes obvious after an incident. When something goes wrong, you need to reconstruct why a specific decision was made — and by then the features have changed, the model has been replaced, and the candidate set is gone.
The minimum worth logging with every prediction: the model version, the feature values actually used, the candidate set considered, the score assigned, and the final decision after business rules. That is enough to replay the decision offline and find out whether the model was wrong, the features were wrong, or a business rule overrode a correct answer.
It is also what makes delayed-label evaluation possible at all, since the outcome that arrives in 90 days has to be attributed back to the model version that caused it.
Key takeaway
The golden signals stay green through every failure that matters in an AI system, so build a second layer: input and output distributions for minutes-level detection without labels, behavioural proxies like reformulation and escalation for hours, and true quality against delayed labels for the real verdict. Slice all of it by segment, because an aggregate can improve while your worst-served group collapses. And design the responses alongside the alerts — a tested non-ML fallback and a model that tolerates a missing feature are worth more at 3am than any dashboard.
Next: the spine, and what the interviewer is actually scoring.