Monitor capacity and availability

Monitoring answers two questions. Can users reach the app right now? Does the server have room to keep serving it next week? A server with free RAM and a broken DNS record is down. A server answering every request with 2% disk left is about to be.

Availability: check from outside

The check that matters runs from somewhere that isn’t the Droplet, against the public URL:

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

--fail makes curl exit non-zero on any 4xx or 5xx status, so a script can act on it. Run it every minute or two from an uptime service or another machine.

Why from outside? A check on the server can’t see broken DNS, a Cloud Firewall rule, an expired certificate or a routing problem. DigitalOcean’s control panel says “powered on” for all of those. Only an outside request tells the truth.

Capacity: know your baseline

Turn on DigitalOcean’s improved metrics and create alert policies for the resources this server uses. Then, on a normal day, record what normal looks like:

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

df -h shows how full each filesystem is. free -h shows memory and swap in use. uptime ends with three load averages, the average number of processes waiting to run over the last 1, 5 and 15 minutes. On a one-CPU Droplet, a sustained load above 1 means work is queuing. The ps line lists the top memory consumers, so when memory grows you know which process owns it.

Without a baseline you can’t tell a problem from a Tuesday.

Set thresholds you can act on

Don’t copy alert numbers from a tutorial. Choose thresholds that leave you time to respond. A disk alert at 99% is useless when a runaway log fills the last percent in minutes. 80% gives you a weekend. A CPU spike for thirty seconds is nothing. CPU pinned for twenty minutes while requests get slow is a real signal.

An alert is a question, not an order to resize

When an alert fires, confirm the user-visible symptom first, then look at the trend. A disk full of logs needs cleanup and rotation, not a bigger disk. Memory climbing for days is a leak, and more RAM only delays the crash. A slow external API stays slow no matter how big the Droplet gets.

For each alert, write a three-line response: where to look, what’s safe to clean or restart, when resizing is the right answer. An alert without a plan is noise you’ll learn to ignore.

Save today’s disk, memory, load and process baseline in your notes. Then set up one external availability alert and one capacity alert, and send a test notification. Make sure it reaches your phone, not an inbox you check weekly.