Monitoring a Cloud Server: The Six Numbers That Matter

A dashboard with forty graphs tells you nothing at 3am. Six metrics and three alerts tell you almost everything.

2 June 2026 3 min read

Monitoring goes wrong in two directions. Too little, and the first sign of a problem is a user complaint. Too much, and alerts get muted, which is functionally the same as too little.

The six numbers

Metric	Healthy	Investigate
CPU usage	Below 70 per cent sustained	Sustained above 85 per cent
Memory used	Below 80 per cent	Above 90 per cent, or swap in use
Disk space	Below 75 per cent	Above 85 per cent
Disk I/O wait	Below 5 per cent	Above 15 per cent
Network in and out	Stable and predictable	Unexplained spikes
Load average	Below core count	Above twice core count

Disk space is the one that causes the most outages and is the easiest to prevent. A full disk stops writes, stops logging, and often stops the database, all at once and without warning.

Application metrics matter more than server metrics

Server metrics tell you the machine is healthy. They do not tell you the service is working. Add four:

Request rate — so you can tell a real spike from an idle system.
Error rate — 5xx responses as a proportion of requests. The single most useful signal there is.
Response time percentiles — p50, p95, p99. Averages hide the experience of the users having a bad time.
Queue depth — for anything with background jobs, this is where problems appear first.

A rising error rate is worth waking someone for. High CPU on a server that is serving traffic correctly is not.

Alert on symptoms, not causes

The distinction is what keeps alerting useful:

Page for: the site is down, error rate is elevated, disk will be full within hours, backups failed.
Notify for: CPU sustained high, memory climbing, certificate expiring within two weeks, unusual traffic.
Record only: everything else, available in dashboards when you go looking.

If an alert fires and the correct response is to do nothing, it should not have been an alert. Move it down a tier the first time that happens, not the fifth.

Uptime monitoring from outside

Everything above runs on or near your infrastructure, so it cannot tell you the site is unreachable from the internet. An external check does.

Check from multiple locations, so one network problem does not create a false alarm.
Check a real endpoint that exercises the application, not a static file.
Alert only after two or three consecutive failures.
Monitor certificate expiry at the same time; it is a free addition and a common outage cause.

Logs: enough to answer questions

Log in a structured format, ideally JSON, so fields can be queried.
Include a request identifier that follows a request across services.
Configure rotation on day one, or logs become the disk-space alert.
Ship logs off the server, so a failed instance does not take the evidence with it.
Never log credentials, tokens, card numbers or personal data.

What to use

Provider monitoring — included with DigitalOcean, Linode, Hetzner, UpCloud and the hyperscalers — covers the six server metrics and basic alerting at no extra cost. That is enough for a small estate, and it needs no setup.

Beyond that, Prometheus with Grafana is the standard self-hosted stack, and hosted observability platforms trade cost for not running it yourself. Start with what the provider gives you and add more when you have a specific question it cannot answer.

Common questions

How long should I keep metrics?

Thirteen months lets you compare against the same period last year, which is when seasonal patterns become visible. High-resolution data for two weeks and downsampled data beyond that is a common compromise.

Is high load average always bad?

No. Load counts processes waiting for CPU and, on Linux, for disk. A load of 4 on 8 cores is fine. Compare against core count, and check I/O wait before concluding it is CPU.

Should alerts go to email?

For notifications, yes. For anything that needs a response within the hour, use something that makes noise — a phone alert or an on-call system. Email at 3am is not an alert.

What is the minimum worth setting up?

Provider monitoring with three alerts — disk above 85 per cent, memory above 90 per cent, and an external uptime check. That takes fifteen minutes and catches most outages before users do.

Where to go next

See how to size a cloud server, which depends on these numbers, and audit logging for the security side.

DigitalOcean Hetzner Linode