Check Filesystem Capacities

What the Linux filesystem capacity monitor does

This Automox Worklet™ inspects every mounted filesystem on a Linux endpoint and reports any partition at or above 90% disk utilization. The Worklet runs df -H to retrieve human-readable usage statistics, then pipes the output through grep and awk to isolate real storage volumes. Virtual filesystems, snap package mounts, tmpfs entries, and CD-ROM media are filtered out before evaluation.

For each remaining partition, the Worklet extracts the use percentage and the mount point, compares the percentage to a hard-coded ALERT threshold of 90, and writes a timestamped log line when the partition is over the limit. Each alert names the partition, the current use percentage, and the endpoint hostname, so the activity log line stands on its own without a cross-reference to the policy run.

The evaluation script returns exit 1 unconditionally, which routes execution to the remediation script on every policy run. That is intentional. This Worklet is a recurring audit, not a one-time fix, and the remediation script holds the df scan and the alert logic.

Why audit filesystem capacity at fleet scale

A Linux endpoint that runs out of disk space fails in ways that are hard to diagnose after the fact. Journald and rsyslog stop writing, so the audit trail vanishes the moment you most need it. PostgreSQL and MySQL abort transactions and refuse new connections. Build agents, package managers, and container runtimes return ENOSPC errors that surface as silent CI failures or pods stuck in CrashLoopBackOff. The 90% threshold gives you a window to act before any of that happens.

A full /var, /tmp, or /var/log on a Linux host triggers a cascade. Docker stops pulling images, journald drops events, package installs fail mid-transaction, and the platform team learns about it from an unrelated 3 a.m. page. Run this Worklet across the RHEL, Ubuntu, Debian, and container-host fleet to get a current per-host capacity map in the Activity Log before paging conditions develop. Trend the alert lines alongside the rest of your storage-health signal.

How the 90% capacity audit works

1. Evaluation phase: The evaluation script is intentionally minimal. It calls exit 1, which marks the endpoint as non-compliant and triggers the remediation script on every policy run. That pattern turns the Worklet into a recurring audit, and it lets you schedule the monitor on the same cadence as your other compliance Worklets.

2. Remediation phase: The remediation script runs df -H and pipes the output through grep -vE "/snap|^Filesystem|tmpfs|cdrom" to drop the header row and non-storage mounts. The awk stage prints the use percentage and mount point as two columns. The check_space function reads each line, strips the trailing % with cut, compares the integer to the ALERT variable (90), and writes a timestamped alert with the date, partition, percentage, and hostname for any breach. If no partition breaches the threshold, the function writes "No drives low on space." to the activity log.

Capacity audit requirements

• Linux endpoint with bash and the GNU coreutils toolchain (RHEL, CentOS, Rocky, Alma, Fedora, Debian, Ubuntu, and other mainstream distributions)

• Standard utilities df, awk, grep, cut, and date on the endpoint PATH (present by default on every supported distribution)

• Permission to read mount metadata; the Automox agent runs as root, so no additional configuration is required

• FixNow enabled for on-demand audits when an admin needs a live capacity snapshot outside the scheduled policy window

• Optional: edit the ALERT=90 variable at the top of remediation.sh to tighten the threshold for storage-sensitive endpoints (databases, container hosts) or relax it for archive volumes

Expected output after a capacity audit run

On a healthy endpoint, the Automox Activity Log records a single line: "No drives low on space." That line is your green signal for the policy run. On an endpoint with one or more partitions over the threshold, the log contains one alert per offending mount. The alert format is: "Wed Apr 17 09:14:22 UTC 2026 : Running out of space \"/var (94%)\" on server web-03". The hostname, partition, and percentage are all captured, so triage does not require a follow-up SSH session.

To validate locally before scheduling the policy, run df -H on a target endpoint and confirm the columns the script reads (use percentage in column 5, mount point in column 6) match your expectations. Run bash remediation.sh directly and confirm the alert format. To exercise the alert path on a healthy endpoint, drop ALERT to a value below the busiest partition's current use, run the script, and check the log line. Reset ALERT to 90 after testing.

Schedule this Worklet on the same cadence as your other compliance checks. A daily run fits most fleets; storage-sensitive hosts can move to every four hours. Aggregate the alert lines across endpoints in the Automox console to spot trends. Watch for hosts that consistently approach 90%, partitions like /var, /tmp, or /var/log that drift first, and build or backup jobs that correlate with capacity spikes. Treat the Worklet output as the leading indicator that lets you clean log retention, archive old data, or expand the volume before a service outage.