A municipal payment portal must page on-call staff when HTTP 5xx rises and also when successful payment count stays at zero for fifteen minutes during office hours. How should the city developer design CloudWatch alerting?
Select an answer to reveal the explanation.
Short Explanation
Alarming like a fire panel that watches smoke and a silent cash register—both matter. Pair the usual 5xx technical signal with a business metric that payments still succeed during office hours, or quiet failures slip past. That combo catches broken tech and a healthy-looking API that stopped taking money.
Full Explanation
A municipal payment portal that must page on-call staff when HTTP 5xx rises and also when successful payment count stays at zero for fifteen minutes during office hours needs alarms on both technical and business metrics, scoped to office-hour windows. Technical 5xx catches platform failure; a payments-succeeded business metric catches "silent success collapse" where requests may look fine-ish but money movement stops—exactly the dual-signal design city developers should implement in CloudWatch.
Alarming only on Lambda duration assumes zero payments always mean the function is slow, which misses many failure modes.
Disabling technical alarms and relying on a weekly spreadsheet cannot page anyone within fifteen minutes.
Paging only when X-Ray sampling is 100% confuses tracing cost controls with payment-success alerting.
Exam caveat: Combine infrastructure metrics with business KPIs and time windows when the stem demands both failure and "zero success" detection.
Operational check: Create CloudWatch alarms on 5xx and on payments_succeeded (EMF or PutMetricData) with office-hour schedules, route to SNS/pager, and simulate zero-payment and 5xx conditions in a test stage before production cutover. Keep the civic/municipal context in mind: cashiers and finance notice payment freezes immediately; paging must match that urgency during business hours.