The attributes behind your decision
- Decision input
- Measured workload
- Primary variables
- Capacity, control, operations
- Validation
- Representative testing
- Next step
- Swiss infrastructure
Begin with service-level symptoms
Check availability, response time, error rate and critical transactions from outside the server. A machine can look healthy while the application is unavailable.
Observe resource pressure and queues
Track CPU saturation, run queues, memory pressure, disk latency, filesystem capacity, network errors and connection pools. Use trends and workload context instead of isolated percentages.
Alert on actionable conditions
Define ownership, severity and response steps for each alert. Avoid thresholds that constantly fire without action, and test notification delivery during staffed and unstaffed periods.
Connect monitoring to incident recovery
Link alerts to dashboards, logs, runbooks and escalation contacts. Review incidents to improve detection and verify backups and restoration separately.
Alert on a failure someone can act on
Track application availability alongside CPU, memory, disk space, storage latency and network behavior. A machine can respond to ping while its database or checkout is broken. Add an application check that exercises a safe, representative request and distinguish user-facing failures from background warnings.
For each alert, define an owner, an escalation path and an action to investigate. Establish a baseline before choosing thresholds. Test that notifications arrive, document planned-maintenance handling, and review repeated alerts so noise does not hide a genuine outage or an approaching capacity limit.