A water utility's leak-detection anomaly model begins producing an unusual spike in invocation errors overnight, and on-call staff need to be paged automatically rather than discovering the problem the next morning. Which setup achieves this?

A CloudWatch alarm configured on the endpoint's invocation error-rate metric continuously evaluates that metric and, once it crosses a defined threshold, triggers a notification action that can page on-call staff immediately, exactly the real-time response an overnight spike demands. A weekly emailed report surfaces the problem days later, long after leak detection may have gone dark during the incident window. A dashboard that requires someone to look at it manually each morning depends entirely on human timing and attention, precisely what failed here, since nobody was watching overnight. An automatic retraining pipeline triggered by an accuracy-metric change addresses model quality, not operational failures like invocation errors, and retraining on error-corrupted data overnight could make things worse. Scope caveat: the alarm threshold needs tuning against normal error-rate variance, since a threshold set too tight pages staff for routine noise, while one set too loose delays a real incident response. A concrete operational check: review the alarm's recent trigger history to confirm it fired promptly when the overnight error spike actually began.