Monitoring, Alarms and Alerts

The example service is monitored through a combination of infrastructure metrics, application metrics, and synthetic checks against its public endpoints.

Alarms are configured with two severity levels: warnings, which are posted to a team channel for awareness, and critical alerts, which page the on-call engineer. Thresholds are set to minimize noise — a single slow request should not page anyone, but a sustained error rate should.

Common alarms include elevated error rates on the API endpoint, database connection pool exhaustion, and disk usage above a defined threshold on any application server. Each alarm links back to the relevant troubleshooting page so the on-call engineer has a starting point.