A service goes down not because of a bad deploy but because /var/log quietly filled the last few gigabytes of disk overnight, and a two- or three-person ops team finds out from a user complaint, not a dashboard.
Disk usage monitoring best practices for devops teams in 2026 come down to a short list: which metrics actually predict failure, what thresholds trigger an alert before the disk is full, and how much of that you can run with a handful of scripts before you need anything heavier.
Small teams either skip disk monitoring entirely (running df -h from memory when something feels slow) or bolt on a full observability platform sized for a hundred-engineer org. Neither fits. This guide covers what to actually check, the alert thresholds worth setting, how to find what’s eating your disk before it becomes a 3am page, and when a script-based setup stops being enough. For the wider picture of what else to track alongside disk, see our complete guide to linux server monitoring.
What does good disk usage monitoring look like for a small devops team?
Good disk monitoring for a small team isn’t complicated, it’s just consistent. Four things, checked on every host, on a schedule, with someone actually notified when a number crosses a line:
- Usage percentage per mount point, not just the root filesystem
- Inode usage, not just block usage
- A growth trend over days or weeks, not a single point-in-time reading
- An alert that fires before the disk is full, with enough lead time to act
The failure mode this fixes isn’t exotic. A log file grows unbounded. A backup job stops cleaning up after itself. A docker volume accumulates layers nobody prunes. None of these show up as a spike. They show up as a slow climb that a single df -h run, checked once a week, will always catch too late.
None of this requires a dedicated observability hire. A two- or three-person team can cover all four with a script and a cron entry, which is the setup this guide builds toward, and still know exactly which host to look at before anyone else notices.
Which disk metrics matter beyond df -h?
Usage percentage per mount point, not just root
Running df -h alone tells you the root filesystem is fine while /var or a mounted data volume is at 95%. Check every mount point that matters on the host, not just /:
df -h --output=target,pcent,used,availOn a typical small ops setup that’s /, /var, /home, and whatever’s mounted for application data or backups. A monitoring script that only checks / will miss the exact partition most likely to fill first.
Inode exhaustion: the “disk full” that df -h won’t show you
A filesystem can report plenty of free space and still refuse to write a single new file, because it’s run out of inodes, the metadata entries a filesystem allocates for every file and directory from a fixed pool set at format time. This happens most often on hosts that create huge numbers of tiny files: session caches, mail queues, or log rotation gone wrong (thousands of small rotated files instead of a handful of compressed ones).
df -i --output=target,ipcent,iused,iavailCheck inode usage percentage alongside block usage percentage. A host at 40% disk usage but 98% inode usage is closer to an outage than the raw disk number suggests.
Growth rate over time, not a single snapshot
A single df -h reading tells you where a disk is, not where it’s going. 70% used could be stable for months, or it could be 70% because it jumped 20 points overnight. Log the usage percentage on a schedule, a cron job appending to a file or a real monitoring tool’s history, and alert on rate of change, not just the absolute number. A host climbing 5% a day at 60% used is a more urgent problem than one sitting steady at 85%.
What alert thresholds should devops teams set for disk usage monitoring?
Two-tier thresholds: warning at 80%, critical at 90-95%
A single threshold gives you no lead time. Two tiers give the team a chance to act before it’s an incident:
- Warning at 80%: routed to a low-urgency channel, triaged during normal hours
- Critical at 90-95%: pages whoever’s on call, treated as urgent
The exact critical number depends on how fast that host’s disk usually grows. A host that fills 1% a week can sit at a 95% critical threshold safely. A host that fills 1% a day needs the critical line closer to 90%, because the lead time between “critical” and “full” is what determines whether anyone can actually act.
Concretely: a build server that fills up during a busy release week behaves nothing like a database host that grows a steady half a percent a day. Treat the first as a warning that needs a quick cleanup, and the second as one that needs a capacity conversation, not the same 90% page for both.
Why one static threshold fails on log-heavy or database hosts
An 80/90 threshold that works fine on a stateless app server is often wrong for a database host or a log aggregator, where disk usage naturally sits higher as a matter of design (write-ahead logs, retained WAL segments, indexes). Applying one blanket threshold across every host either pages constantly on the hosts that are supposed to run hot, or misses the hosts that actually have no headroom left. Set thresholds per host role, not globally: a database host might warn at 85% and go critical at 95%, while a stateless web server warns at 70% because there’s no good reason for it to be that full at all.
Alerting on trend vs. a fixed number
The most useful alert isn’t “disk is at 91%”, it’s “disk usage is climbing at a rate that hits 100% within 48 hours”. That requires storing at least a few days of history per host and computing a simple linear projection, not just comparing the latest reading to a fixed line. It’s a small amount of extra logic that turns a threshold alert into an actual early warning.
How do you find what’s actually eating disk before it’s a crisis?
du -sh */ | sort -rh and ncdu for a human-readable breakdown
Once a threshold has fired, the next question is always the same: what’s actually taking up the space. From the root of a suspect mount:
du -sh */ | sort -rh | head -20That gives a ranked, human-readable list of the biggest directories one level down, then repeat inside whichever one is largest. For anything beyond a one-off check, ncdu (NCurses Disk Usage) does the same walk interactively, letting you drill into directories without re-running the command each time:
sudo apt install ncdu && ncdu /varThe usual suspects: unrotated logs, orphaned docker images/volumes, package caches, core dumps
The same handful of causes show up on almost every host that fills unexpectedly:
- Unrotated or misconfigured logs in
/var/log, especially application logs outside the standardlogrotateconfig - Orphaned docker images, stopped containers, and dangling volumes (
docker system dfshows the breakdown,docker system prunereclaims it) - Package manager caches (apt, yum, npm, pip) that grow unbounded without a periodic clean
- Core dumps from crashing processes, often left in
/var/crashor wherevercore_patternpoints, silently accumulating
Docker is worth calling out on its own: unused images stack up fast on a host that rebuilds often, and a stopped container’s writable layer sticks around using disk until something explicitly removes it. Run docker system df first to see how much is reclaimable before reaching for docker system prune, so you’re not deleting a cache you’ll immediately rebuild.
Checking these four first, before a deeper investigation, resolves the majority of “disk suddenly full” incidents on a small team’s infrastructure.
How do you build a lightweight disk monitoring setup without a new platform?
A cron + df + alert script for a handful of servers
For a handful of servers, a real monitoring platform is often more setup than the problem justifies. A cron job that runs df on a schedule, checks the output against per-mount thresholds, and posts to a webhook (Slack, a paging service, email) when a line is crossed covers the same ground with a script and a cron entry:
*/15 * * * * /usr/local/bin/check-disk.sh >> /var/log/check-disk.log 2>&1The script itself is short: parse df -h --output=target,pcent, strip the percent sign, compare against a threshold map per mount, and curl a webhook when a line crosses warning or critical:
#!/usr/bin/env bash
set -euo pipefail
WARN=80
CRIT=90
WEBHOOK="https://hooks.example.com/disk-alerts"
df -h --output=target,pcent | tail -n +2 | while read -r mount pcent; do
pct="${pcent%\%}"
if (( pct >= CRIT )); then
level="critical"
elif (( pct >= WARN )); then
level="warning"
else
continue
fi
curl -s -X POST "$WEBHOOK" \
-H "Content-Type: application/json" \
-d "{\"level\":\"$level\",\"mount\":\"$mount\",\"used\":\"$pcent\",\"host\":\"$(hostname)\"}"
donePoint WEBHOOK at a Slack incoming webhook, a paging service’s HTTP endpoint, or even a simple mail relay. It’s not sophisticated, but it’s the difference between finding out from a monitoring channel and finding out from a user, and it runs on any host with bash and curl already installed.
Log rotation and cleanup as prevention, not just cure
Alerting catches a full disk after the fact. Log rotation and scheduled cleanup prevent it from happening at all. Confirm every service writing logs has a working logrotate entry (size or time-based, with compression and a retention count), and add a scheduled job for docker cleanup and package cache clearing rather than relying on someone remembering to run it manually:
docker system prune -af --volumes --filter "until=168h"Prevention is cheaper than detection. A host that never accumulates unrotated logs in the first place doesn’t need its disk-usage alert to be perfectly tuned.
When script-based checks stop scaling and you need a real dashboard
A cron-and-webhook setup works well up to somewhere around a dozen or so hosts. Past that, per-host threshold maps, script maintenance across different distros, and the lack of any historical view (trend, growth rate, cross-host comparison) start costing more time than the platform they were avoiding. That’s the point to move to something that tracks disk alongside CPU, RAM, and uptime in one place with history and alerting built in, rather than maintaining that logic by hand across a growing fleet. Our guide to monitoring CPU, RAM, and disk without third-party tools covers the script-based approach in more depth if you’re not there yet, and pairs with keeping an eye on uptime alerts for the same hosts.
Where does termique fit into a small team’s disk monitoring workflow?
termique is a cross-platform SSH manager built for exactly this kind of small ops team: it already has the SSH session open to every host, so it also tracks CPU, RAM, disk, and uptime for each one, refreshed every 30 seconds, with custom alert thresholds per host instead of one global number. That’s the two-tier, per-host-role threshold approach above, without maintaining a script for it. Alerts include a push notification to mobile when a server goes offline or crosses a threshold, so the team finds out from termique before a user notices.
This monitoring shipped in v0.3.0. Whether you’re on the free tier’s 3 hosts or Pro’s unlimited hosts and snippets for $5/month ($3.33/month billed annually, $40/year), monitoring runs on every host connected, it’s not a separate feature to unlock. For a team already living in termique for SSH access, disk monitoring is one less tool to run in parallel.
Disk usage monitoring best practices: a quick recap
Disk usage monitoring for a small ops team doesn’t need a new platform to get right. It needs the right four metrics (per-mount usage, inode usage, growth trend, and a threshold that fires with lead time), two-tier alerting per host role, and a habit of checking what’s actually consuming space before it becomes urgent.
Start with a cron script if that’s all a handful of servers needs, and move to a tool that already sees every host, like termique, once the number of servers or the number of thresholds to maintain by hand stops being worth it. See the complete guide to linux server monitoring for how disk fits alongside CPU, RAM, and uptime, or download termique free to start monitoring disk usage across your hosts today.
