Disk space monitoring and alert thresholds

Choose a threshold that leaves time to respond

A useful disk-space alert tells you which volume needs attention, what is consuming its headroom and how long the team has to act. A percentage alone cannot answer those questions. Ten per cent free on a 100 GiB system volume is 10 GiB; the same percentage on a 10 TiB data volume is 1 TiB. Either can be urgent if its next write is large enough.

I would start with the service and its operational reserve, then work backwards from the response time. Decide how much space the workload needs for ordinary writes, temporary work and approved recovery operations. Include the time to investigate, approve a change, add capacity and verify the result. A capacity warning should arrive before that window closes.

Treat the example thresholds below as a design exercise, not universal defaults. Use one consistent unit in your calculations: GiB means 1,073,741,824 bytes, while GB means 1,000,000,000 bytes. Record which one your monitoring tool displays.

Calculate a warning from growth and lead time

Use a simple model before reaching for a complicated forecast: time to reserve = (current free space minus required reserve) divided by positive net growth per day. The reserve is the space you intend to keep available, not a target of zero bytes. If free space is already below it, the threshold has already been breached.

For a fictional 500 GiB application volume, suppose 80 GiB is free, the agreed reserve is 20 GiB and representative net growth is 12 GiB per day. There are 60 GiB of usable headroom, giving five days to reserve. If expansion and verification take three days and you want a two-day contingency, work should begin now.

At 24 GiB per day, the same headroom lasts only 2.5 days. That faster-growth case is already shorter than the three-day expansion window. Record both cases instead of treating the five-day estimate as a promise. A scheduled import, backup or runaway log can invalidate a linear forecast immediately.

For a zero or negative growth estimate, mark time to reserve as unavailable or not currently declining. Do not divide by zero or display infinite safety. Retain absolute-space checks and allow for known one-off operations. Derive the trend from representative measurements that include busy periods and retention cycles.

• Plan capacity and expansion lead times

Separate warning, urgent and recovery conditions

Use a warning to create planned work and an urgent condition when the approved response window is at risk. Keep a separate hard floor for the minimum space needed to operate. Explicitly decide whether rules combine with AND or OR: requiring both low percentage and low bytes can suppress an important large-volume alert.

For the fictional volume above, one possible design is a warning when estimated time to reserve reaches five days, an urgent condition when it falls below three days, and an immediate response when free space reaches the 20 GiB reserve. The organisation must set its own urgency from service impact; these values are not Microsoft, Paessler or Zabbix defaults.

Persistence reduces noise from brief fluctuations, but a waiting period must be short enough for the workload. A rapidly growing database log may not tolerate a long delay. Use a different recovery condition or a sustained recovery interval so a volume hovering at the limit does not repeatedly open and close tickets.

Each notification should name the host, volume identifier or mount path, service owner, observation time, free space, threshold and next action. Send planned capacity work to a ticket queue. Route imminent service impact through the agreed escalation path.

Inspect Windows volumes with PowerShell

On a Windows host with the Storage module, Get-Volume exposes capacity and remaining space for volumes. This local, read-only example selects fixed volumes with a positive size and reports their identifiers, capacity and free percentage. Path is included because a volume need not have a drive letter.

PowerShell uses binary multipliers for 1GB, so the calculated columns are labelled GiB. Rounding is for display only; use the original bytes for rule evaluation. Run with the approved read permissions for your environment. If collection fails, investigate the error rather than converting the failure into a healthy zero-result report.

This is a point-in-time inventory, not an alerting service. Scheduling it does not automatically provide trend storage, notification delivery or escalation. Reconcile the returned volumes against the workloads you intended to cover, including volumes without drive letters.

• Use the safe PowerShell automation checklist

Get-Volume -ErrorAction Stop |
    Where-Object { $_.DriveType -eq 'Fixed' -and $_.Size -gt 0 } |
    Select-Object DriveLetter, FileSystemLabel, Path,
        @{Name='SizeGiB'; Expression={[math]::Round($_.Size / 1GB, 2)}},
        @{Name='FreeGiB'; Expression={[math]::Round($_.SizeRemaining / 1GB, 2)}},
        @{Name='FreePct'; Expression={[math]::Round(100 * $_.SizeRemaining / $_.Size, 1)}}

Monitor the storage layers that can actually fill

A healthy guest volume does not prove that its backing storage has enough space. Monitor the relevant guest filesystem, virtualisation datastore or storage pool and backup repository separately. In thin-provisioned environments, logical allocation and physical consumption answer different questions.

Include workload-specific constraints such as quotas, reserved space and retained snapshots. On Linux filesystems that use inodes, inode exhaustion can prevent new files even when free bytes remain; the Zabbix Linux templates document separate inode alerts. A byte-only dashboard can miss that failure.

Exclude a volume only for a documented reason. Removing a noisy mount point from discovery is not the same as fixing its threshold. Record expected volumes so a disappeared mount, collection failure or changed identifier cannot silently remove coverage.

• Understand RAID and backup responsibilities

Choose a collection method that your team can operate

A local script is useful for checking a host or understanding the numbers. A monitoring platform is usually the better next step when you need history, per-volume limits, missing-data detection, ownership and reliable notifications across several machines. Evaluate those functions before buying a tool.

Paessler documents percentage and free-byte limits for its WMI Free Disk Space (Multi Disk) sensor, with interactions between sensor-wide and channel settings. Check both layers when adjusting an existing installation. Do not assume a percentage change has disabled a byte-based rule.

Zabbix provides Linux filesystem discovery and space/inode triggers in its published templates. Review the template and macros for the version you deploy, then tune the relevant filesystem rather than copying an expression from an older article. A documented capability still needs an end-to-end acceptance check in your environment.

• Compare server monitoring tools for small IT teams
• Compare RMM tools for small IT teams

Test the notification path without filling production storage

Use a supported test event, a temporary rule against a safe existing value, or an isolated lab volume. Check collection, evaluation, message delivery, acknowledgement, escalation and recovery separately. A successful notification test does not prove that discovery covers every required volume.

Confirm the missing-data case as well as the low-space case. Pause an authorised lab collector or use the platform’s supported test mechanism, then verify that stale data cannot be mistaken for healthy capacity. Restore the original rule and collection state when the check ends.

When a real alert arrives, identify the growth source and service owner before deleting files. Apply the workload’s supported retention, log management or expansion procedure. Do not delete database files, backups or snapshots simply because they look large. After an approved change, verify both available space and application behaviour.

Use the worksheet below to record the reserve, growth assumptions, trigger logic, owner and acceptance evidence. Review the rule after an incident, storage expansion or major workload change. The aim is a small number of alerts that lead to a timely, repeatable response.

• Reduce alert fatigue without hiding incidents
• Review the wider server monitoring checklist