Separate symptoms from causes
A useful page tells an on-call engineer that action may be needed now. CPU, disk, memory and process counts are valuable diagnostics, but a short resource spike is not always a user-visible incident. Pair infrastructure signals with the application journeys and service objectives they affect.
Start by listing alerts triggered in a recent period. For each one, record its owner, response, customer impact, whether action was taken and whether another alert described the same incident. Keep the sample period and environment consistent when comparing changes.
Improve the alert
An actionable alert should identify the affected service, observed condition, duration, severity and a link to a runbook or dashboard. Use a sustained window or an appropriate error-budget signal where the service has a defined objective. Avoid picking a universal CPU percentage for every workload.
Group related notifications when your monitoring system supports it. Route alerts to an accountable team and test escalation if the first responder does not acknowledge. Planned maintenance may justify a time-limited silence, but the silence should have an owner and an expiry.
Keep the evidence
Reducing pages does not mean deleting metrics or hiding an outage. Retain diagnostic signals and use lower-priority notifications or dashboards for trends that do not require immediate intervention. Make missing telemetry visible; an absent metric is not automatically a healthy service.
After a change, compare paging volume, time to detection and missed incidents over a representative period. Revisit thresholds after architecture or traffic changes, and rehearse the response with a controlled test.
Further reading
Read the official documentation. For help applying these checks, explore Clouvenix services.