Deploying a machine learning model into production is a major milestone—but it’s only the beginning of its lifecycle. A model is fitted to a snapshot of the world, and the world keeps moving. Monitoring is what tells you when the gap has grown large enough to matter.
Why Monitoring Matters in Production
A model’s accuracy is measured at training time under conditions that will not persist. Customer behaviour shifts, upstream schemas change, sensors drift out of calibration, a competitor changes pricing, a pandemic rewrites demand. None of these produce an error message. The model keeps returning confident predictions that are quietly getting worse.
The failure is asymmetric in a way that makes it dangerous: a model that crashes gets fixed within the hour, while a model that degrades by two percentage points a month can run for a year before anyone notices, and by then every downstream decision it informed is suspect.
Types of Drift to Track
The word “drift” covers several distinct phenomena with different causes and different remedies. Writing $P(X)$ for the input distribution and $P(Y \mid X)$ for the relationship between inputs and target:
Covariate shift (data drift) means $P(X)$ changes while $P(Y \mid X)$ stays fixed. The population entering the model has changed but the underlying relationship holds. A credit model seeing a younger applicant mix is still correct about how age relates to risk; it is just operating where it has less training data.
Concept drift means $P(Y \mid X)$ itself changes. The relationship the model learned no longer holds — fraud patterns adapt to detection, so the same transaction features now imply a different risk. This is the serious case, because no amount of reweighting fixes it; the model is wrong, not merely extrapolating.
Label shift (prior probability shift) means $P(Y)$ changes while $P(X \mid Y)$ holds. Disease prevalence rises without symptoms changing. This mostly breaks calibration and thresholds rather than ranking, and can often be corrected by adjusting the decision threshold rather than retraining.
Upstream data issues are not really drift at all but produce identical symptoms: a renamed column, a unit change from miles to kilometres, a nullable field that starts arriving null. These are the most common cause of sudden production degradation and the easiest to catch with schema validation.
Distinguishing them matters because the responses differ. Covariate shift may call for reweighting or collecting data in the new region; concept drift requires new labels and retraining; label shift calls for recalibration; a schema break calls for a fix upstream and possibly a rollback.
Core Practices for Monitoring Model Drift
Monitor Outcomes First, Inputs Second
The temptation is to monitor input distributions because they are available immediately. But input drift is a leading indicator with a high false-positive rate — features shift constantly without harming performance, and alerting on every shift produces fatigue that gets the alerts ignored.
Where ground truth arrives, even with delay, monitor realised performance directly. That is the quantity you actually care about. Input monitoring is what you fall back on when labels are slow or absent, not the primary signal.
Where labels are delayed by months, techniques that estimate performance without them — confidence-based performance estimation, for instance — are more informative than raw distribution distance.
Choose Drift Metrics Deliberately
For univariate numeric features, the Kolmogorov-Smirnov statistic and Population Stability Index are standard. PSI is common in credit risk, with rough conventions of below 0.1 for no meaningful shift and above 0.25 for significant shift.
Two cautions. Statistical tests on large production samples will flag differences that are real but trivially small, because power grows with sample size — prefer effect-size style measures such as PSI or Wasserstein distance over p-values. And univariate monitoring misses changes in the joint distribution: two features can each keep their marginal distribution while their correlation inverts completely. Multivariate approaches such as PCA reconstruction error, or training a classifier to distinguish training from production data, catch what per-feature tests cannot.
Monitor Predictions and Calibration
The output distribution is cheap to track and often the first place trouble shows. A model whose average predicted probability drifts from 0.12 to 0.19 is telling you something even before labels arrive.
Calibration deserves separate attention from discrimination. A model can keep its ranking intact — unchanged AUC — while its probabilities become systematically wrong, which breaks every downstream decision that multiplies a probability by a cost.
Alerting That People Will Act On
Alert fatigue is the main failure mode of drift monitoring in practice. A dashboard nobody reads and a channel full of amber warnings are worse than no monitoring, because they create the appearance of oversight.
Practices that help: set thresholds from observed historical variation rather than from published rules of thumb; require persistence, so a metric must breach for several consecutive windows before paging; separate severity levels, with degraded performance paging someone and a feature shift merely logging; and always route an alert to a named owner with a defined action.
Retraining Workflows
Retraining should be a decision, not a reflex. Scheduled retraining on a fixed cadence is simple and often adequate, but it retrains when nothing has changed and waits when something has. Triggered retraining responds to monitored degradation and is more efficient, at the cost of needing trustworthy triggers.
Whichever you choose, the pipeline needs the same discipline as the original: a held-out evaluation the new model must beat, a champion-challenger comparison rather than blind replacement, versioned data and model artefacts so a regression can be traced, and a rollback path. A retrained model that silently performs worse is a strictly worse outcome than leaving the old one running.
Be careful about retraining on production data that the model itself influenced. If the model denies credit to a group, no outcomes are observed for them, and retraining on the resulting data entrenches the original decision. This feedback loop is a well-documented failure mode and needs explicit handling, usually through exploration or reject inference.
Tools
MLflow tracks experiments, parameters and model versions, giving the registry and lineage that make rollback possible.
Evidently and NannyML are drift-specific: Evidently produces distribution and performance reports, while NannyML focuses on estimating performance when labels are delayed, which is the situation most production teams actually face.
Seldon and KServe handle serving with the traffic-splitting needed for shadow deployments and canary releases.
Great Expectations validates data against declared schemas and constraints. It is not a drift tool as such, and it catches the most common production failures — nulls, ranges, types, cardinality — before they reach the model at all.
Where to Start
If nothing is monitored today, the order that yields most per unit of effort is: schema and null-rate validation on inputs, then prediction distribution, then realised performance once labels arrive, then feature drift, then multivariate drift. Most production incidents are caught by the first two, which are also the cheapest to build.
The underlying point is that a deployed model is a claim that the world still resembles its training data. Monitoring is how that claim gets checked, and retraining is what you do when it stops being true.
References
- Sculley, D., et al. (2015). Hidden technical debt in machine learning systems. Advances in Neural Information Processing Systems, 28.
- Quiñonero-Candela, J., Sugiyama, M., Schwaighofer, A., & Lawrence, N. D. (Eds.). (2009). Dataset Shift in Machine Learning. MIT Press.
- Gama, J., Žliobaitė, I., Bifet, A., Pechenizkiy, M., & Bouchachia, A. (2014). A survey on concept drift adaptation. ACM Computing Surveys, 46(4), 1-37.
- Breck, E., Cai, S., Nielsen, E., Salib, M., & Sculley, D. (2017). The ML test score: a rubric for ML production readiness. IEEE Big Data, 1123-1132.
- Klaise, J., Van Looveren, A., Cox, C., Vacanti, G., & Coca, A. (2020). Monitoring and explainability of models in production. arXiv:2007.06299.
