Start with the four that matter
Comprehensive monitoring can be added later. These four catch the majority of real problems and can be configured in an afternoon.
- Is it up? An external check that requests a real endpoint from outside your infrastructure.
- Is the disk filling? Disks reaching capacity is one of the most common and most preventable outages.
- Is it overloaded? Sustained high CPU or memory pressure, rather than brief spikes.
- Are errors rising? A change in error rate is the earliest signal that something has broken.
Check from outside
Monitoring that runs on the server cannot tell you the server is unreachable. An external check that makes a real request from elsewhere is what catches network failures, expired certificates and misconfigured firewalls.
Have it request an endpoint that exercises the application and its database, not a static file. A health check that returns 200 while the database is down is worse than none, because it produces false confidence.
Alert on symptoms, not on causes
Alerting on every metric produces noise, and noisy alerting gets ignored. That is worse than no alerting at all, because the one real alert arrives among fifty that were not.
Alert on things a user would notice: the site is down, requests are failing, responses are slow. Investigate causes with dashboards after the alert fires.
Certificate expiry deserves its own alert
An expired TLS certificate takes a site down completely, and it happens on a schedule you can see in advance. Alert at least a couple of weeks before expiry, even with automatic renewal configured, because renewal itself can fail quietly.
Keep logs somewhere they survive
Logs on a failed server are logs you cannot read. Ship them somewhere central, ideally outside the account, and set a retention period that balances usefulness against cost.
Log volume is a real cost at scale. Keep application logs long enough to investigate, and be selective about debug-level output in production.
Test that the alert reaches a human
Configure an alert, then deliberately trigger it. Confirm the notification arrives, at the right place, and that whoever receives it knows what to do.
An alerting system nobody has tested is an assumption, and the moment you find out it does not work is the moment you needed it.
Related cloud accounts
This guide applies across providers. The cloud account catalogue lists every platform with its configurations and prices, and the comparison table puts them side by side.
Further reading
- Amazon SES Accounts: What You Get and How to Choose a Configuration
- AWS vs Oracle Cloud: Which Cloud Account Should You Buy?
- Azure vs Oracle Cloud: Which Cloud Account Should You Buy?
- Oracle Cloud vs IBM Cloud: Which Cloud Account Should You Buy?
Frequently asked questions
An external uptime check and a disk space alert. Those two catch a surprising share of real incidents.
Only on sustained pressure, not on spikes. Brief high CPU is normal and alerting on it trains people to ignore alerts.
Somewhere off the server, ideally outside the account, so they survive the failure you need them to explain.
