In January an NBFC puts a lead-scoring model live. The launch numbers look fine and the team moves on to the next feature. In August a sales manager in Jaipur notices that the high scores no longer match who actually takes a loan. Nothing failed loudly; the data the model sees drifted away from the data it was trained on, and nobody was measuring the gap.
Why a working model stops working
A trained model is a snapshot of the relationships in its training data. The world keeps moving after the snapshot is taken.
A marketing push brings in applicants from Tier-2 cities the model rarely saw. A pricing change shifts loan sizes. A form field gets reworded and people start filling it in differently. An upstream system renames a category. The model knows none of this, and it keeps producing confident scores from patterns that no longer hold.
Ordinary service monitoring does not notice, because nothing broke. The code did not change, so there was no deploy. The service answers every request, so there is no error. What changed is the meaning of the inputs and outputs, and that is the thing model monitoring has to measure.
Four numbers to log on every request
Two of these are about the model and two are about the service hosting it. All four come from data you already have at request time.
- 01Requestfeature values recorded
- 02Model
- 03Predictionscore, latency, failures recorded
- 04Baseline comparethis week against training data
Both recorded points feed the same comparison against the training set.
Input drift
Compare the distribution of each feature over the last day or week with its distribution in the training set. A numeric feature whose average or spread has moved, a category that did not exist at training time, a field that is suddenly empty in most requests. Each of these is input drift. It is the earliest warning you get, because it shows up before the predictions have had time to be wrong.
Take a form redesign that drops the "employer type" field. The model starts receiving blanks where it used to see "salaried" or "self-employed". The scores still come out. They just mean less, and the input check is the only thing that will tell you.
Output drift
Compare the distribution of predictions with what the model produced in its first weeks. If the share of leads scored as high-intent doubles, either the leads got better or the model is reacting to something else, such as a festive-season campaign bringing in a different crowd. You do not know which yet. You do know to look.
Latency and errors
Record the time from request to prediction and watch the slow tail, not the average. A model that slows down as traffic grows will hit the caller's timeout long before anyone looks at the model, and the caller will quietly fall back to a default.
Count the requests the model could not answer: missing features, malformed input, a failed feature lookup, a timeout. Many applications hide these behind a default value, so count them at the model boundary where they are still visible.
One log line per request is enough to hold all of it. Something like this, written by the serving code, not reconstructed later:
{"ts": "2025-12-02T10:41:07Z", "request_id": "r-88213",
"model_version": "lead-score-2025-01-14",
"features": {"employer_type": null, "loan_amount": 350000, "city_tier": 2},
"score": 0.81, "latency_ms": 42, "error": null}
A weekly check against real outcomes
Drift tells you the inputs or outputs changed. It does not tell you whether the predictions are still right. For that you need the actual outcome, which usually arrives late: the lead did or did not become a loan, the invoice was or was not paid on time.
Set up a small routine. Each week, take a sample of recent predictions, attach the outcome once it is known, and compute the same accuracy measure that was used when the model was approved. Keep the sample size fixed so the number is comparable week to week, and plot it next to the drift numbers.
Where no outcome arrives on its own, have a person label a few dozen cases. Half a day of an analyst's time each week is cheap next to a model that has been wrong for a quarter.
What gets an alert and what gets a chart
Alert on everything and the team mutes the channel within a fortnight. Alert on nothing and the drift chart is something a person opens after a complaint.
- Error rate above the agreed line
- Slow-tail latency above the caller's timeout
- A feature missing, or a new category, in most requests
- Weekly labelled accuracy below the approval level
- Small input drift on one feature
- Output distribution moving slowly
- Traffic volume changes
- Latency rising but still inside budget
The rule we follow: an alert goes to a named person who can act on it, and it fires on a threshold agreed before launch. Everything else goes on a chart that the same person reads once a week next to the labelled-sample result. One chart, one person, one slot in the calendar. Write the thresholds down before go-live, because a threshold set after the first incident is set by whoever is most annoyed.
When the weekly check does show a real decline, the next question is whether to retrain and how. We cover that in retraining on a schedule versus on a signal.
How model monitoring gets skipped
The most common mistake is monitoring the service and assuming the model is covered. Uptime and request counts say nothing about whether the predictions are still right.
Next is logging predictions without the feature values behind them, so when drift is suspected there is nothing to compare. Then there are the missing labels, because the outcome lives in the loan management system and nobody built the join to the scoring log.
Two mistakes are about timing. Thresholds get set after the first incident instead of before launch, so the first incident is found by a customer or by the sales head. And this week gets compared with last week instead of with the training set, so slow drift never trips anything, because each week looks like the one before.
The last one is ownership. A dashboard with no named reader becomes the dashboard nobody opens.
The first-week setup
Do this in the week the model goes live, in production, not in staging:
- Log every request's features, prediction, latency, failures and model version.
- Store a summary of the training set's feature distributions next to the model artefact.
- Run a daily job comparing the last day's features and predictions with that summary.
- Build the join to outcomes and run a weekly accuracy check on a fixed-size sample.
- Write down four alert thresholds and the person each one goes to.
Start with the request log. Every other check reads from it, and a model that has run for a month without one has already lost the data you would need to see what changed. The same log is what makes a safe shadow run or canary for the next version possible, and it is part of the MLOps work listed under our AI solutions.
