MLOps model monitoring is the practice of tracking a machine learning model's inputs, outputs and accuracy after deployment, so teams can detect data drift, concept drift and data quality problems before they hurt business results. A complete setup monitors four layers: data quality, input and prediction distributions, model performance against ground truth, and the serving infrastructure, with alerts tied to clear response steps.
A model that scored well on its test set can still fail quietly in production. Customer behaviour changes, upstream data pipelines change, and fraud patterns evolve. None of this shows up as an error message; the model keeps answering, just less accurately. This guide explains why models degrade, what to monitor, how to design alerts, which tools teams use, and how monitoring changes for large language models (LLMs).
Why Model Monitoring Is Different From Application Monitoring
Application monitoring tools such as Prometheus, Datadog and New Relic track uptime, latency and error rates. Those signals matter for ML systems, but they only tell you that the model is responding. A model can return a prediction in 12 milliseconds with a 200 status code and still be wrong. Model monitoring adds the statistical layer that tells you whether the model is still right.
|
Monitoring layer |
Primary signals |
What it catches |
|---|---|---|
|
Infrastructure and serving |
Latency, throughput, error rate, resource use |
Outages, slow endpoints, capacity problems |
|
Data quality |
Missing values, schema violations, out-of-range values, new categories |
Broken upstream pipelines and schema changes |
|
Distribution (drift) |
Feature and prediction distribution shift |
Data drift and early signs of degradation |
|
Model performance |
Accuracy, precision, recall, AUC, error metrics against ground truth |
Confirmed loss of accuracy |
|
Business outcome |
Conversion, loss rates, revenue impact |
Misalignment between model output and business goals |
Why Models Degrade: 4 Root Causes
1. Data drift (covariate shift)
The distribution of input features changes after deployment while the model's learned parameters stay fixed. A credit model trained on pre-pandemic spending behaviour, for example, scores a population whose income and spending patterns no longer look like its training data.
2. Concept drift
The relationship between inputs and the target changes, even when inputs look stable. A fraud model may see familiar transaction features while a new attack pattern maps them to different outcomes. Concept drift can be sudden (an abrupt change), gradual (slow change over weeks or months), recurring (seasonal patterns) or incremental (steady movement in one direction, such as inflation affecting price-based models).
3. Label shift (prior probability shift)
The share of each outcome changes. A model calibrated on a 5% fraud rate will under-predict if the real rate rises to 15%. Recalibrating thresholds is a quick fix; retraining on recent data is the durable one.
4. Training-serving skew
The features computed in production differ from those used in training, because of different preprocessing code, features not available in real time, or different handling of null values. No real-world change is needed for this to happen. Shared feature definitions, often through a feature store, and consistent data pipelines are the main prevention.
What to Monitor: Key Metrics
Data quality metrics
-
Missing value rate: per feature and time window. A sudden jump usually means a pipeline failure, not model decay.
-
Out-of-range rate: values outside the bounds seen in training.
-
Schema compliance: expected fields, types and no unexpected columns.
-
New categories: unseen values in categorical features that can break encoding.
Drift metrics
-
Population Stability Index (PSI): widely used in regulated industries. A common rule of thumb treats PSI below 0.1 as stable, 0.1 to 0.25 as moderate shift worth investigating, and above 0.25 as significant shift. Calibrate thresholds for your own features.
-
Kolmogorov-Smirnov (KS) test: compares distributions of continuous features between a reference window and current data.
-
Jensen-Shannon divergence: a bounded, symmetric measure that works for categorical features and prediction scores and handles empty bins better than KL divergence.
-
Maximum Mean Discrepancy (MMD): suited to high-dimensional data, including embeddings from deep learning models.
-
Prediction score distribution: shifts in predicted probabilities often appear before accuracy metrics move.
Performance metrics
-
Classification: accuracy, precision, recall, F1, ROC-AUC, average precision and calibration error. Calibration matters when probabilities drive decisions, such as risk scores.
-
Regression: MAE, RMSE, MAPE and error percentiles, since tail errors are often where the cost is.
-
Segments: report by customer group, region or product. Aggregate metrics can hide a sharp drop in one segment.
Business metrics
Connect model output to outcomes the business tracks, such as approval rates, fraud losses, churn saved or conversion. A model can stay statistically stable while its business value falls.
Good monitoring starts with good data. See why data quality matters in analytics and the data requirements for predictive AI models.
Monitoring Architecture
A production monitoring setup is a data pipeline with three inputs:
-
Prediction logs: input features, model output, model version and timestamp for every request.
-
Ground truth labels: actual outcomes, joined to predictions when they become available.
-
Reference data: the training set or a recent production window used as the baseline for drift tests.
The label delay problem
Labels often arrive late. Churn outcomes may take 30 to 90 days; loan defaults can take years. As a result, performance monitoring lags the real problem. Input and prediction drift monitoring is the early warning; performance monitoring confirms it later. Some tools estimate performance without labels from prediction confidence, which helps close this gap.
Choosing a reference window
-
Fixed reference (training data): simple, but may flag normal evolution as drift.
-
Rolling reference (recent production): adapts to change, but can miss slow drift.
-
Statistical process control (CUSUM, EWMA): detects both sudden and gradual shifts relative to a baseline.
Weight alerts by feature importance
Not every feature matters equally. Weighting drift alerts by feature importance, for example using SHAP values from training, reduces noise from low-impact features and highlights drift that actually changes predictions.
Alert Design: A Tiered Approach
Too many alerts lead to alert fatigue, and real problems get ignored. A tiered design keeps responses proportional:
|
Tier |
Example trigger |
Response |
|---|---|---|
|
Informational |
Moderate drift (PSI 0.1 to 0.25) on low-importance features |
Review in the weekly model health meeting |
|
Warning |
Moderate drift on high-importance features, or rising prediction score shift |
Assigned investigation within an agreed window, for example 48 hours |
|
Critical |
Significant drift (PSI above 0.25) on key features, or performance below threshold |
Same-day response; evaluate rollback or retraining |
|
Incident |
Prediction volume collapse, schema failure or serving errors |
On-call engineer responds immediately |
Write a short runbook for each tier so the person on call knows what to check first and who decides on rollback or retraining.
Model Monitoring Tools
|
Tool |
Type |
Typical use |
|---|---|---|
|
Evidently AI |
Open-source library and cloud platform |
Drift, data quality and performance reports; test suites in CI/CD; LLM evaluation |
|
Arize AI |
Commercial observability platform (open-source Phoenix for LLM tracing) |
Production monitoring, explainability, LLM evaluation |
|
Fiddler AI |
Commercial observability platform |
Monitoring, explainability and bias analysis with governance features |
|
NannyML |
Open-source library |
Estimating performance before labels arrive |
|
Great Expectations |
Open-source library |
Data quality validation in pipelines |
|
Cloud ML platforms |
Built-in monitoring in Azure Machine Learning, Amazon SageMaker and Google Vertex AI |
Drift and data quality monitoring for models hosted on that platform |
Older guides also recommend WhyLabs. WhyLabs announced it was discontinuing operations after Apple acquired rights to its team and technology in 2025, so check vendor status before choosing a platform.
Monitoring LLMs and Generative AI
Classical drift tests do not cover everything that can go wrong with LLM applications:
-
Variable outputs: the same prompt can produce different answers, so quality must be measured across many responses.
-
Quality drift without visible change: answers stay fluent while accuracy or relevance falls.
-
Hallucinations: confident but incorrect statements.
-
Prompt injection: users trying to override instructions, which is a security signal.
Common monitoring methods include:
-
LLM-as-judge evaluation: a separate model scores sampled outputs for accuracy, relevance, tone and policy compliance, with periodic human review to check the judge.
-
Embedding drift: inputs and outputs are converted to embeddings, and shifts in their distribution reveal changes in topics or user behaviour.
-
Reference-based metrics: for tasks with known answers, such as extraction or summarization, semantic similarity metrics like BERTScore give more useful signal than BLEU or ROUGE.
-
Operational metrics: token usage, cost per request, latency and refusal rates.
Closing the Loop: Retraining
Monitoring is only useful if it leads to action. Teams typically combine three retraining triggers:
-
Scheduled: retrain on a fixed cadence, suitable for stable domains.
-
Drift-based: retrain when drift on important features crosses a threshold.
-
Performance-based: retrain when measured performance falls below an agreed level.
An automated pipeline should pull fresh data, retrain, compare the candidate model with the current one on a holdout set, and promote it only if it performs better, with an easy rollback path. For training fundamentals, see how to train an AI model.
Fairness Monitoring and Regulation
Models that affect people, such as credit, hiring or insurance models, should be monitored for differences in outcomes across groups, using measures such as demographic parity difference and equal opportunity difference. Regulation is moving in the same direction. Under the EU AI Act, providers of high-risk AI systems must establish and document a post-market monitoring system, an obligation that applies from 2 August 2026. Check the requirements that apply in your sector and markets with your legal and compliance teams.
A Phased Monitoring Roadmap
|
Phase |
Focus |
Outputs |
|---|---|---|
|
1. Foundation |
Logging and data quality |
Prediction logging, schema checks, serving dashboards, basic alerts |
|
2. Drift detection |
Statistical monitoring |
Drift metrics on key features and predictions, tiered alerts, runbooks |
|
3. Performance and retraining |
Feedback loop |
Label joins, segment-level performance, retraining pipeline |
|
4. Advanced observability |
Scale and governance |
Explainability, fairness monitoring, LLM evaluation, audit reporting |
Common Mistakes to Avoid
-
Monitoring every feature with the same thresholds, which creates alert noise.
-
Adding monitoring after deployment instead of designing it with the model.
-
No runbooks, so alerts arrive but nobody knows what to do.
-
Not monitoring the monitoring pipeline itself; a silent logging failure looks like a quiet, healthy model.
-
Ignoring the cost of storing logs and running drift jobs at scale.
Frequently Asked Questions
What is ML model monitoring?
It is the ongoing tracking of a deployed model's input data, predictions and accuracy to detect drift, data quality issues and performance loss, with alerts that trigger investigation or retraining.
What is the difference between data drift and concept drift?
Data drift is a change in the input data distribution. Concept drift is a change in the relationship between inputs and the outcome, which can happen even when inputs look stable.
How do you monitor a model when labels arrive late?
Monitor input and prediction drift and data quality as early warning signals, use performance estimation tools where suitable, and confirm with actual performance once labels arrive.
What PSI value indicates drift?
A common rule of thumb is below 0.1 stable, 0.1 to 0.25 moderate shift, and above 0.25 significant shift. Teams should tune thresholds per feature.
How often should models be retrained?
It depends on how fast the domain changes. Many teams combine a regular schedule with drift-based and performance-based triggers.
Keep Your Models Earning Their Keep
Model monitoring turns AI from a one-time project into a reliable system. Start with logging and data quality, add drift detection with sensible alert tiers, connect performance and retraining, and extend to fairness and LLM evaluation as your portfolio grows.
