• Home
  • BVSSH
  • C4E
  • Playbooks
  • Frameworks
  • Good Reads
Search

What are you looking for?

Practice : Model Monitoring and Alerting

Purpose and Strategic Importance

AI models degrade silently. Unlike software bugs that cause immediate visible errors, model performance degradation often manifests gradually — as slowly worsening prediction quality, increasing fairness violations, or subtle shifts in output distributions that only become apparent in aggregate. Without continuous monitoring, teams have no reliable signal that their models are performing as intended in production, and users bear the consequences of degraded AI outputs without any visibility or recourse.

Monitoring is also the primary mechanism for closing the feedback loop between deployment and improvement. Production data reveals things that no pre-deployment test suite can surface: edge cases from real user behaviour, distributional shifts driven by changes in the world, and the long-tail failure modes that only emerge at production scale. Teams that monitor rigorously learn from production; those that do not are operating blind.


Description of the Practice

  • Monitors model performance metrics continuously in production, including both technical quality metrics (accuracy, precision, recall, latency) and business outcome metrics (click-through rate, resolution rate, user satisfaction).
  • Detects data drift and concept drift by monitoring the statistical properties of input data and model outputs over time, alerting when distributions shift beyond defined thresholds.
  • Implements fairness monitoring that tracks model performance disaggregated by demographic subgroups, detecting differential degradation that could represent emerging unfairness.
  • Configures alerting with appropriate thresholds and escalation paths, distinguishing between high-priority alerts requiring immediate response and lower-priority trends requiring scheduled review.
  • Maintains monitoring dashboards that give teams operational visibility into model health without requiring deep investigation to assess the current state of production systems.

How to Practise It (Playbook)

1. Getting Started

  • Identify the three to five most critical metrics for each production model — the metrics whose degradation would be most consequential — and implement monitoring for these first.
  • Define alert thresholds for each monitored metric based on historical performance variability and the business impact of degradation at different levels.
  • Implement logging of model inputs, outputs, and prediction confidence in production, creating the data foundation for monitoring and retrospective analysis.
  • Establish on-call responsibilities for AI model monitoring, ensuring that alerts are routed to someone who can respond and that response expectations are documented.

2. Scaling and Maturing

  • Build automated drift detection that monitors input feature distributions and output distributions, not just aggregate performance metrics — drift detection is an early warning system for performance problems.
  • Implement shadow scoring — running the current production model and a candidate replacement simultaneously on live traffic — to enable safe evaluation of new model versions before deployment.
  • Develop monitoring dashboards that surface AI system health alongside related business metrics, making the connection between model quality and business outcomes visible to non-technical stakeholders.
  • Extend monitoring to cover the full serving infrastructure — latency percentiles, throughput, error rates, and resource utilisation — not just model quality metrics.

3. Team Behaviours to Encourage

  • Review monitoring dashboards regularly as part of the team's operational rhythm — not just when an alert fires, but proactively to identify trends before they become incidents.
  • Take monitoring alerts seriously and investigate all triggered alerts, even when initial investigation suggests a false positive — the cost of a missed genuine degradation is usually higher than the cost of an unnecessary investigation.
  • Close the loop between monitoring findings and model improvements — every significant production performance issue should inform the team's development backlog.
  • Invest in reducing alert noise by refining thresholds and improving signal quality, building a monitoring system that the team trusts rather than one it learns to ignore.

4. Watch Out For…

  • Alert fatigue from poorly calibrated thresholds — too many low-significance alerts desensitise teams to monitoring signals and lead to important alerts being ignored.
  • Monitoring that covers only aggregate metrics while missing subgroup-level degradation that may be occurring for specific user populations.
  • Assuming that absence of alerts means absence of problems — monitoring gaps are often invisible until a significant incident reveals them.
  • Building monitoring that captures data but does not connect it to actionable decisions, creating a data graveyard rather than an operational insight system.

5. Signals of Success

  • Model performance degradation in production is detected automatically and triggers an alert within the organisation's defined SLA, measured in minutes or hours rather than days.
  • Monitoring dashboards are reviewed proactively by the team, not only consulted when an alert fires — the team has a habit of looking at model health.
  • Fairness metrics are monitored continuously alongside accuracy metrics, with alerts configured to detect differential performance degradation.
  • When a model incident occurs, the monitoring system provides the data needed to diagnose the root cause rapidly, reducing mean time to resolution.
  • The number of production incidents detected first by monitoring (rather than by user complaints or business impact reports) is tracked and increasing over time.
Associated Standards
  • Post-deployment model performance is monitored continuously
  • Model degradation triggers are defined and monitored in production
  • Production feedback loops are closed within defined time limits

Technical debt is like junk food - easy now, painful later.

Awesome Blogs
  • LinkedIn Engineering
  • Github Engineering
  • Uber Engineering
  • Code as Craft
  • Medium.engineering