Monitoring & alerting
Purpose: Define the golden signals for each AEM tier, the alert set worth waking for, and the dashboards worth trusting.
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Platform engineers | Builders |
| All engineers | Consumers on call |
Golden signals per tier
| Tier | Wake-someone alerts | Dashboard trends |
|---|---|---|
| CDN/Dispatcher | 5xx rate spike; health-check fail; cert expiry <14d | Hit ratio, edge latency, top-miss URLs |
| Publish | Instance out of LB; render p95 breach; thread pool saturation; disk >85% | Uncached RPS, GC pauses, heap, sessions open |
| Author | Replication queue blocked >5min; login failure spike; disk >85%; backup failed | Workflow backlog, DAM ingest queue, active authors |
| Platform-wide | error.log ERROR-rate spike; bundle not Active post-deploy; Sling HC red (endpoints) | Repo size, index lag, integration success rates |
| Business synthetic | Canary journey fails (load PHI plan page, check premium renders) | Journey latency trend |
The synthetic journey is the alert hierarchy's apex: it tests what users experience, through the whole chain, and catches the failures no single-tier check composes into.
Alert design rules
- Every alert: actionable + urgent + runbook-linked (the quality bar).
- Symptoms over causes at the paging layer (page on "site down", not on each of its 12 possible causes — those are diagnostics on the dashboard).
- Rate-based thresholds with sustain windows (ERROR >X/min for 5min) — single log lines don't page.
- Deploy-aware: suppress or annotate during deploy windows; a deploy that pages everyone trains everyone to ignore pages.
Implementation notes
Metrics via JMX exporters (Oak, replication, Sling metrics are all MBean-exposed) into your metrics stack; Sling Health Checks aggregated at /system/health for LB and probe use; log-based alerts from the aggregation platform (log management). Dashboards per tier plus the one-screen overview an incident commander reads at 3am.