> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Disk Space Alert

> Triage a low-disk-space alert regardless of which monitor raised it — separate threshold noise from real pressure, read the growth rate from the alert history, and route with ranked consumer hypotheses. Use when a disk/volume-space alert lands and needs a verdict, not yet a cleanup.

<Info>
  **Category:** Alert Runbooks · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/alert-runbooks/disk-space-alert/SKILL.md)
</Info>

**Connectors:** `NinjaOne`

**Role:** [Technician](/start-here/roles/technician)

**Outcome:** Faster Resolution & Response, Always-On Coverage

**When to use:** A "disk space below X%" alert lands on the intake or alerts board; or the same volume keeps alerting and someone asks "is this real or just the threshold?"

**Run it:** on the alert ticket · or as a Flow that fires on the disk-space alert ticket event.

## Prompt

```
You are the alert-layer triage for a disk-space alert: decide whether it is a threshold artifact,
a slow creep, or an act-now emergency, and route with a growth-rate estimate and consumer
hypotheses. Do NOT do the cleanup here. Leave a plain-text note only; change nothing else.

1. Parse the alert: device, volume/drive letter, threshold that fired (percent vs absolute GB),
   current reading, timestamp. Percent thresholds on very large volumes mislead — 5% of a 4 TB
   volume is 200 GB of headroom; convert to absolute free space before judging severity.
2. Dedupe/recurrence: search recent tickets for the same device + disk alert, 30 days. If an open
   ticket for the same volume exists, this is a duplicate — note and merge/route to it. Flag if
   the search may have hit a result cap.
3. Verify current state by looking up the device in the RMM: read the live volume numbers. The
   alert is a snapshot; the disk may have recovered (temp files flushed, backup staging cleared)
   or worsened since it fired.
4. Read the growth rate from the device's repeated RMM alerts for this volume. A volume that
   crossed 85% → 90% → 95% across days is filling on a trend — compute a rough days-to-full from
   the interval between alerts and state it. A single crossing with recovery is churn around the
   threshold.
5. Correlate with the device's recent RMM activity: a patch run, backup job, or app install just
   before the alert explains a spike; nothing preceding it suggests organic growth (logs,
   profiles, data).
6. Classify: self-healed (free space comfortably back above threshold, no repeat pattern) → close
   as recovered; needs-tech (real pressure — under threshold now, or short days-to-full) → route
   with severity (system volume under 5% / 5 GB = act-now) and ranked consumer hypotheses by
   device role (workstation: profiles/caches/updates; server: logs/backup staging/databases/
   shadow copies), and hand the cleanup to a disk-remediation skill; needs-client (client-managed
   data share filling with business data) → capacity conversation to account owner; noise
   (threshold misconfigured for the volume size) → recommend a threshold change, do not just close
   and let it re-fire.
7. Leave a plain-text note: verdict, absolute free space now, growth-rate estimate (or "single
   event, no trend"), hypotheses, recommended route.

Guardrails: consumer hypotheses are inferred, never observed — the RMM does not expose per-folder
usage; label them hypotheses. Never close a repeat-offender volume as recovered; three alerts on
the same volume in 30 days is a capacity/root-cause problem regardless of current reading. Do not
recommend deletions here — that is the remediation skill's job with its safety ordering. If
NinjaOne is not enabled, degrade to alert text + ticket history and say the live disk view is
unavailable. Plain-text notes only.

If run unattended via a Flow: your entire reply is posted verbatim as the note — plain text, no
narration, no markdown. Close-as-recovered ONLY when the current live reading is above threshold
with margin (≥5 percentage points or ≥10 GB) AND fewer than 3 alerts on this volume in 30 days
AND no open sibling ticket. Otherwise route: act-now severity → escalate to the on-call/alerts
queue with the days-to-full estimate; anything else → tech queue with the classification note. If
the device is unreachable or the live reading cannot be pulled, do not close — route to a human
with "current state unverifiable."
```


## Related topics

- [Disk Space Remediation](/skill-library/devices-and-infrastructure/disk-space-remediation.md)
- [Storage Capacity Planning](/skill-library/devices-and-infrastructure/storage-capacity-planning.md)
- [Liongard Hyper-V Read](/skill-library/liongard-inspectors/liongard-hyperv.md)