Set server alerts from a realistic understanding of the workload. A useful threshold identifies a condition that needs action, with enough time to respond before customers are affected.
IN THIS ARTICLE
01 Establish the baseline
- Confirm that the authorised monitoring agent reports the correct server. Shared-hosting users should use supplied account metrics and support rather than installing a system agent without permission.
- Observe a representative business cycle, including peaks, backups and scheduled jobs. Compare CPU, memory, storage and network behaviour with application response times.
- For each metric, define the failure you want to prevent. Disk free space needs a growth forecast; sustained CPU pressure needs workload context; memory needs interpretation for the operating system.
- Create an alert for the relevant metric and target servers, choosing the condition, threshold and duration before opening.
- Assign a responder and a specific first action. Separate an early capacity warning from an urgent service-impact condition where your alert design supports it.
- Review the results after a deployment or upgrade and adjust the baseline deliberately.
02 Example: turn free space into a response deadline
Suppose an authorised server report shows 25 GB of usable free space and the recent workload grows by about 2 GB per day. A simple planning estimate is:
Estimated time to full = usable free space / observed daily growth
25 GB / 2 GB per day = about 12.5 daysThis is a rough forecast, not a guarantee. A backup, import or log spike can consume space faster, and operational work needs spare capacity before the disk is full. Compare several representative days and identify which filesystem is growing.
Expected result: the alert threshold leaves enough time for the named responder to investigate growth, review retention and arrange a capacity change where justified. Set the warning for the actual server and filesystem rather than copying one percentage across every machine. Recheck the trend after the corrective work and record whether the growth rate changed.
Common questions
Is one threshold appropriate for every server?
Different roles, capacities and workloads produce different normal values. Tag or group servers carefully and avoid applying a database threshold to an unrelated web workload without review.
Does high memory usage always mean a problem?
Operating systems use memory for caches as well as applications. Examine available memory, pressure, swapping and the application symptoms rather than relying on one percentage.
Can an alert buy more resources automatically?
Monitoring and resource changes are separate unless an explicitly configured automation handles them. Define who investigates and approves a capacity change.