Observability is a large field and most small deployments need a small part of it. The failure mode is not “no dashboards”; it is finding out from a customer that the site has been down since Saturday.
Four signals worth watching
- Is it answering? An external check that requests a real URL from outside your network and expects a real response — not a ping, and not a check that runs on the server being checked.
- Disk space. The most common cause of a server that is up and broken. Logs, snapshots, package caches and database write-ahead files all grow quietly.
- Memory pressure and swap activity. The early warning for the failure described in how much RAM a cloud server needs.
- Error rate. The rate of 5xx responses, or of exceptions, over time. This catches the failures where the machine is perfectly healthy and the application is not.
CPU utilisation is deliberately not on that list. It is the most watched and least actionable metric on a small server: high CPU with acceptable latency is a machine doing its job.
Three alerts worth having
- The site is not responding — from an external checker, after two consecutive failures so a single blip does not wake anyone.
- Disk above 80% — a warning with days of runway, not a page at 99%.
- Spend above the expected monthly figure — see setting a cloud budget alert. A cost alert is a monitoring alert; it frequently detects the same incident as a technical one.
Everything else can be a dashboard you look at deliberately rather than a notification that interrupts you.
Keep alerts worth reading
An alert channel that fires daily is a channel nobody reads, which is worse than no alerting at all because it feels like coverage. Two rules keep it healthy:
- Every alert must have an action. If the answer to “what do I do about this” is “nothing”, it is a metric, not an alert.
- Any alert that fires and requires no action gets fixed or deleted the same week.
Logs
Centralise them if you have more than one server; otherwise the local journal with sensible rotation is genuinely fine. Two things matter more than where they live: that timestamps are synchronised across machines, and that log rotation is configured before the disk fills. Shipping logs off-platform continuously is also a steady egress cost, which is worth knowing before you enable it everywhere.
When to graduate to a real stack
A full metrics-and-tracing stack starts paying for itself when you have more than a handful of services, when requests cross service boundaries so a single log file no longer tells the story, or when you need historical comparison to answer “was this slow last month too”. Below that, it is infrastructure you now have to run, monitor and pay for.
Where to go next
- What an uptime SLA actually promises
- Autoscaling: what it fixes and what it hides
- Cutting cloud costs without downtime
Questions
Frequently asked
What should I monitor on a single cloud server?
External availability, disk space, memory pressure and application error rate. Those four catch the large majority of incidents on a small deployment.
Why is CPU usage not a useful alert?
High CPU with acceptable response times means the machine is working. Alert on the symptom users experience — latency or errors — rather than on utilisation.
Do I need a monitoring service, or is the provider's dashboard enough?
The provider's metrics cover the instance but cannot tell you the site is unreachable from the internet. At minimum, add an external uptime check that runs outside your own infrastructure.