Disk Space Alert

Alert-layer triage for a disk-space alert: threshold artifact, slow creep, or act-now emergency?
Route it with a growth estimate and consumer hypotheses.

1. Parse the alert: device, volume, threshold fired (percent versus absolute GB), current
   reading, timestamp. Percent thresholds on large volumes mislead: 5% of a 4 TB volume is 200 GB
   of headroom, so convert to absolute free space before judging severity.

2. Check recent tickets for this device and volume, 30 days. An open ticket on the same volume
   makes this a duplicate: note it and route there.

3. Read the live volume numbers: the alert is a snapshot, and the disk may have recovered (temp
   files flushed, backup staging cleared) or worsened since. Then read growth from repeated RMM
   alerts on this volume: crossing 85%, then 90%, then 95% across days is a filling trend, so
   compute a rough days-to-full from the alert intervals. A single crossing with recovery is
   churn around the threshold. Correlate with recent RMM activity too: a patch run, backup job or
   app install just before the alert explains a spike; nothing preceding it suggests organic
   growth (logs, profiles, data).

4. Classify, then note it — plain text, no markdown or emojis (PSA Note Discipline base skill):
   verdict, absolute free space now, growth estimate (or "single event, no trend"), hypotheses,
   route. Self-healed (free space back above threshold with margin, no repeat): close as
   recovered. Needs-tech (under threshold now, or a short days-to-full): route with severity — a
   system volume under 5% or 5 GB is act-now — and ranked consumer hypotheses, labelled as
   inferred since the RMM has no per-folder view (workstation: profiles, caches, updates; server:
   logs, backup staging, databases, shadow copies). Needs-client (client-managed share filling
   with business data): capacity conversation, account owner. Noise (threshold misconfigured for
   the volume): recommend a threshold change, don't just close and let it re-fire.

Never close a repeat offender as recovered: three alerts on one volume in 30 days is a capacity
problem whatever the current reading. Don't do the cleanup or recommend deletions here; that is
the remediation skill's job with its safety ordering. If the RMM isn't connected, apply the
Connector Degradation base skill: fall back to alert text and ticket history, and saying the live
view is unavailable.

As a Flow: your entire reply is the note. Close as recovered ONLY when the reading is above
threshold with margin (5 percentage points or 10 GB), there are fewer than 3 alerts on this
volume in 30 days, and no sibling ticket is open. Act-now: escalate to the on-call queue with the
days-to-full estimate. Everything else: tech queue with the classification. If the device is
unreachable or the reading won't pull, route to a human marked "current state unverifiable" —
never close.