Monitor capacity and availability

Monitoring answers two different questions: can users reach the application, and does the server have enough capacity to keep serving it?

Monitor the public HTTPS endpoint from outside the Droplet. The check should require a successful status and run often enough to notice useful downtime:

curl --fail --silent --show-error https://notes.example.com/health

An internal process check cannot detect broken DNS, a provider firewall, an expired certificate, or a failed route. Keep an external check even when DigitalOcean reports that the Droplet is powered on.

Enable DigitalOcean improved metrics and create alert policies for the resources relevant to this server. On the Droplet, collect a baseline during normal use:

df -h
free -h
uptime
ps -eo pid,comm,%cpu,%mem --sort=-%mem | head
systemctl is-active nginx notes-app

df shows filesystem capacity. free shows memory and swap. uptime includes load averages. Process data helps connect pressure to an owner.

Do not alert on one universal number copied from a tutorial. Choose thresholds that leave time to respond. A disk alert at 99% is too late when logs can grow quickly. A short CPU spike may be harmless, while sustained high CPU with slow requests needs investigation.

When an alert fires, verify the user-visible symptom and the resource trend before resizing. A full log directory needs cleanup and retention. A memory leak needs a code or process fix. A slow external API will not become healthy because the Droplet has more RAM.

Write a small response for each alert: where to look, what can be cleaned or restarted safely, when to resize, and who receives the notification. Monitoring without an action becomes noise.

Your action is to save today’s disk, memory, load, and process baseline, then configure one external availability alert and one capacity alert. Trigger or test the notification path so you know it reaches you.