What this prompt does
This prompt writes a Bash disk monitoring system for a [server_role] server with [filesystem_layout]. It checks mounted filesystems every [check_interval] minutes, alerts at [warning_threshold]% and [critical_threshold]% via [alert_method], calculates growth over [trend_window] days to predict the full date and warn if within [prediction_alert_days] days, lists the top [top_n] largest directories and files using depth-limited du, runs guarded cleanup of [cleanup_patterns] at critical, tracks inode usage, generates a weekly HTML capacity report, and emits metrics for [monitoring_system].
The variables tune sensitivity and safety. [warning_threshold] and [critical_threshold] set the alert tiers, [trend_window] and [prediction_alert_days] drive the predictive full-date warning, and [cleanup_patterns] defines exactly what automated cleanup may delete. The inode tracking matters because many small files can exhaust inodes before the disk itself fills, a case plain usage graphs miss.
When to use it
- You want to avoid the avoidable outage of a server filling its disk at 3am
- Predicting when a filesystem will hit 100% rather than only reacting at full
- Tracking inode usage alongside disk space for small-file-heavy workloads
- Reporting the top
[top_n]largest directories on filesystems over threshold - Adding guarded automated cleanup at the critical threshold
- Emitting capacity metrics into
[monitoring_system]for dashboards
Example output
You get a Bash script that checks each mount in [filesystem_layout], sends tiered alerts via [alert_method], computes growth rate and a predicted full date, lists the largest items with depth-limited du, performs guarded cleanup of [cleanup_patterns] only at critical, reports inode usage, writes a weekly HTML capacity report, and outputs metrics in the format [monitoring_system] expects.
Pro tips
- Define
[cleanup_patterns]conservatively; automated deletion of the wrong pattern is worse than a full disk, so scope it to clearly safe files - Set
[warning_threshold]low enough to give lead time before[critical_threshold]triggers disruptive cleanup - Trust the inode tracking — a filesystem can show plenty of free space yet refuse new files because inodes are exhausted
- Tune
[trend_window]to your workload; too short a window makes the predicted full date jumpy, too long smooths over a sudden spike - Keep du depth-limited as the prompt specifies, or scanning a large
[filesystem_layout]can itself add I/O load during an incident - Route critical alerts through
[alert_method]to a channel that pages someone; a warning in a quiet Slack channel will not save a 3am disk-full - Schedule the weekly HTML capacity report somewhere people actually read it; trend and growth-rate data only prevents outages if someone acts on it before the predicted full date arrives
- Set
[check_interval]against how fast[filesystem_layout]can fill; a busy/datapartition may need tighter checks than/, since a fifteen-minute gap can be too coarse for a fast-growing mount