High CPU/Memory Alert

Triage a CPU or memory alert. A 90-second CPU peg during an AV scan and a server at 95% for six
hours look identical here. Never reboot or kill anything — this is triage.

1. Parse the alert: device, metric (CPU and memory are different playbooks), threshold, observed
   value, sample duration. A 5-second sample means almost nothing; a 15-minute average means a
   lot.

2. The device's RMM alert history over 30 days is the spike-versus-sustained instrument; read it
   with recent tickets on the same metric. One alert with a recovery is a spike; alerts recurring
   daily at the same hour are a scheduled-workload pattern (backup, scan, report job); continuous
   or escalating is sustained pressure.

3. Read current utilization, uptime and device class (long uptime with creeping memory alerts
   suggests a leak), and correlate recent RMM activity with the alert timestamps: patch installs,
   AV scans, backup jobs and update downloads are benign spikes; a new app installed just before
   the pressure began is a prime suspect.

4. Offer top-consumer hypotheses, LABELLED as such (the RMM shows no live per-process data).
   Workstations: browser sprawl, AV scan, sync clients, video calls, a runaway update. Servers:
   database growth, an IIS or app-pool leak, backup and dedup jobs, terminal-server user load,
   runaway logging.

5. Classify, then note it — plain text, no markdown or emojis (PSA Note Discipline base skill):
   metric, the verdict and its evidence, hypotheses, route. Self-healed (spike recovered, no
   recurrence): close with that evidence. Needs-tech (sustained, or recurring outside a benign
   scheduled job): route with hypotheses and the RMM deep link — on a workstation a reboot
   usually cures it or the hardware is undersized, so merge in any user slowness ticket; on a
   server never suggest a casual reboot, treat it as a capacity or workload-fault investigation,
   and put any restart in a maintenance window. Needs-client (client-owned workload): account
   owner. Noise (threshold too tight for the duty cycle): recommend threshold or schedule tuning,
   don't just close.

Confirm the scheduled job exists in the activity before calling a recurring alert noise.
Recurring sustained pressure is a capacity problem: don't present the third "it recovered" as
resolution. If the RMM isn't connected, apply the Connector Degradation base skill: fall back to
alert text and ticket history, and say the live view is unavailable.

As a Flow: your entire reply is the note. Close ONLY when utilization is back under threshold AND
it is the device's first such alert in 30 days. Recurrence of 2+ on the same scheduled window:
threshold-tuning, state the pattern. Still above threshold: escalate on a server, tech queue on a
workstation. Never close a server alert on recovery alone once recurrence reaches 2. Unverifiable
state: route to a human, never close.