How to Monitor Machine Learning Models in Production

Green dashboards, wrong answers

The usual set-up looks reassuring. The prediction service has uptime checks, response times are fine, error rates are near zero. Meanwhile the model has been scoring every new customer as low risk for three weeks because a field started arriving empty and the code filled it with a default.

Standard application monitoring would never catch that. The service was healthy. It was confidently wrong. Monitoring a machine learning model means watching the things ordinary monitoring was never designed to see.

The four layers to monitor

The first three give you early warning. The fourth gives you the truth, usually late. You need both, because a model can pass the first three and still be failing, and an outcome report that arrives three months late is no use as an alarm.

Log every prediction, properly

None of the useful monitoring works without a prediction log. It is the single most valuable thing to build, and it is often skipped because nobody asks for it.

• A unique ID that can be joined to the eventual outcome
• Timestamp and model version
• The input features exactly as the model saw them, after processing
• The prediction and any confidence score
• What the business did with it, if that differs, for example a human override

Store it somewhere queryable, like a PostgreSQL table or your data warehouse. For high-volume systems, sampling is fine for inputs, but keep every prediction ID so outcomes can still be joined. The storage cost is modest next to the cost of not being able to answer what the model did last Tuesday.

Setting alerts people will not ignore

Monitoring fails socially more often than technically. Send ten alerts a day and within a fortnight nobody reads them.

1. Alert only on things someone would act on today: the job did not run, missing values jumped, the prediction distribution collapsed to one class.
2. Put gradual changes, like slow drift in a feature average, in a weekly report rather than an alert.
3. Set thresholds from the model's own history, not from textbook values.
4. Name the person who receives each alert and what they are expected to do.
5. Review alert rules after the first month and delete the ones nobody acted on.

An alert without an owner and an action is just noise with a timestamp.

Monitoring outcomes when labels are slow

When you cannot know if a prediction was right for months, look for earlier proxies. A churn model might be checked against support tickets or reduced logins before the cancellation arrives. A lead score can be checked against whether sales accepted the lead, long before the deal closes.

Proxies are imperfect, so label them as such in the report. They are still far better than waiting a quarter to find out the model stopped working in week two. The ideas here overlap with our post on model drift, which is the most common thing this monitoring catches.

Mistakes we see in model monitoring

• Only watching the average. Overall accuracy holds steady while one region or customer type falls apart. Break reports down by the segments the business cares about.
• Monitoring the wrong metric. Accuracy on a fraud model where 99 per cent of transactions are genuine tells you almost nothing. Track the errors that cost money.
• Forgetting human overrides. If staff overrule the model on a third of cases, that is a signal in its own right, and it also means the outcome data is shaped by people rather than the model.
• Letting the report die. The weekly email keeps arriving long after anyone reads it. Put the review in someone's calendar and ask them to note one sentence each week.

None of these is technically hard to fix. They persist because monitoring gets set up at launch and never revisited.

Tools, briefly

You do not need a specialist product to start. A scheduled SQL query that writes a few numbers to a dashboard, plus alert rules in whatever you already use for application monitoring, covers most small deployments. Open-source libraries such as Evidently can generate drift reports if you want more depth, and the cloud ML platforms include monitoring features if you are already on one.

The right time to buy a dedicated monitoring tool is when you have enough models that maintaining the custom checks has become a job in itself. For one or two models that point rarely comes. If you are running language model features rather than classic models, monitoring an AI app has somewhat different concerns.

What we set up by default

For every model SpiderHunts deploys through our machine learning work, the minimum is a prediction log, input checks that run with each batch or hourly for live services, a prediction distribution chart, and a weekly outcome report where outcomes exist. Each alert has a named owner on the client side.

It is not glamorous and it adds perhaps a week to a project. It is also the difference between hearing about a problem from a chart and hearing about it from your finance director.

Frequently asked questions