VPS Resource Alerts: Which Thresholds Are Worth Waking Up For

Most monitoring setups fail in one of two ways: either nobody configures alerts until after an outage, or alerts are configured so aggressively that the operator learns to ignore them. Both outcomes are expensive. The useful middle ground is a small number of thresholds tied to genuine failure modes, each with a clear response. Here is how to build that set for a budget VPS without paying for enterprise monitoring.

Why Most Alerts Get Ignored

Alert fatigue is a design problem, not a discipline problem. If a system sends forty notifications a week and three of them matter, the operator will eventually stop reading them. The fix is to separate conditions that require action from conditions that merely require awareness, and to route them differently.

A practical split: anything that requires intervention within an hour goes to a channel that makes noise. Everything else goes to a daily digest that gets reviewed once.

The Thresholds That Actually Matter

On a small instance, five metrics account for nearly all preventable outages. Each has a different warning horizon, which is why fixed percentages alone make poor thresholds.

Metric	Suggested Trigger	Lead Time	Urgency
Disk usage	80% and 90%	Days to weeks	Low, then high
Available RAM	Sustained <15% free for 10 min	Hours	High
Swap activity	Any sustained swap-in rate	Hours	High
Load average	>2x vCPU count for 15 min	Minutes	Medium
Service reachability	Two consecutive failed checks	Immediate	Critical

Note that disk usage gets two thresholds. The 80% warning is a planning signal — you have time to clean up or resize. The 90% trigger is an operational one, because filesystems degrade sharply and some services fail outright when they cannot write.

Rate of Change Beats Absolute Values

A disk at 60% is fine. A disk that went from 30% to 60% in six hours is an incident in progress, usually a runaway log file or a stuck backup rotation. Absolute thresholds miss this entirely.

If your monitoring tool supports derived metrics, alert on slope as well as level. A simple rule like “disk grew more than 10 percentage points in 24 hours” catches leaks days before a capacity alert would fire, and it is one of the highest-value alerts you can configure on a small instance.

Instrumenting Swap Correctly

Swap usage is widely misunderstood. A system with 2 GB of swap and 200 MB in use is not necessarily unhealthy — the kernel may have paged out cold data that is never needed again. What matters is swap activity, meaning pages actively moving between RAM and disk.

• Alert on page-in rate (pswpin from vmstat), not on swap occupancy.
• Ignore steady-state occupancy from workloads that loaded once and went idle.
• Investigate any sustained page-in above zero that is not caused by a known one-off job.

Sustained swap-in on an SSD-backed instance is survivable for a while. On a host with slow storage it is a performance cliff. Either way, it is a signal that your working set has outgrown your RAM tier, and the correct response is usually a resize rather than further tuning.

Building This Cheaply

You do not need a hosted monitoring service to cover these five signals. A lightweight agent such as Netdata or node_exporter consumes 30–80 MB of RAM, which is a real cost on a 1 GB instance but negligible on 2 GB or more. If even that is too much, a cron job writing metrics to a log and a small script comparing against thresholds works for everything except service reachability.

For reachability specifically, run the check from outside the instance. An agent on the same box cannot report that the box is down. External uptime checkers with a free tier are adequate for a single site, and they catch the failure mode that internal monitoring structurally cannot see.

Choosing a Plan That Gives You Room

Alerts are a safety net, not a substitute for adequate capacity. A plan that runs at 85% memory utilization at idle has no burst headroom and will page under any load increase. When you size an instance, budget for the monitoring agent itself plus a 30–40% margin above your measured steady state.

It helps to compare budget VPS plans side by side with headroom as an explicit column in your comparison, not just the headline RAM figure.

Related reading: how much spare memory to keep covers sizing margins, and what happens when a VPS disk fills up explains why the 90% threshold is not arbitrary.

Disclosure: some links on this page are affiliate links. If you sign up through them we may earn a commission at no extra cost to you.

Need more headroom? Find VPS plans with memory and storage margins built in →