Vendor-neutral checklist for supported server operating systems and applications. Thresholds must be calibrated to the workload; no universal CPU or disk threshold is implied.
Research-based; no hands-on test claim.Start at the service boundary
List the operations users depend on and how you can check them safely. A health endpoint, a synthetic transaction or a supported database probe gives different evidence from a ping. Decide what successful behaviour looks like and which failures require immediate action.
Record service ownership, maintenance windows and dependencies. A network outage can make many hosts appear down; avoid treating every symptom as an independent incident. Monitor the monitoring system and its notification delivery too.
Collect a small useful baseline
Capture availability, request volume, errors and latency where the application exposes them. Add host CPU, memory pressure, storage latency, free capacity and network errors to explain symptoms. Preserve enough history to compare normal working periods, scheduled jobs and unusual load.
A single average can hide a short but serious delay. Choose an aggregation and time window that match the user impact. Do not collect detailed logs indefinitely without considering sensitivity, storage cost and access control.
Attach a response to each alert
For each proposed notification, write what the responder should do and how quickly. An alert that nobody can act on may belong in a report instead. Use persistence windows or recovery thresholds where brief fluctuations would otherwise create noise.
The worksheet below separates checks from responses. Fill in actual thresholds after observing the service. Include growth rate and lead time for capacity alerts: a volume with substantial free space may still need action if it is filling faster than capacity can be added.
| Signal | Question | Response record |
|---|---|---|
| Availability | Can the user operation complete? | Owner, dependency checks and escalation |
| Latency/errors | Is service quality degrading? | Time window and diagnostic evidence |
| Capacity | When will headroom be exhausted? | Growth rate and expansion lead time |
| Collection | Are metrics or checks missing? | Agent, credentials and monitoring health |
Test the complete route
Use a controlled test to verify collection, rule evaluation, delivery, acknowledgement and escalation. Do not create an outage merely to prove a notification. A supported test event or isolated service can validate much of the route.
Review alerts after incidents and changes. Remove obsolete hosts, correct owners and check credentials before they expire. Keep dashboards for investigation, but make sure urgent conditions reach a person without requiring somebody to watch a screen continuously.