A PROCESSOR SPIKE ISN’T THE WHOLE STORY.
This is a hypothetical example of my approach. It is not a delivered client project, a Commercial Networks result or a promised outcome.
A fictional example of separating brief CPU spikes from sustained performance incidents.
(180 − 45) × 4 assumed minutes ÷ 60 = 9 hours per month, before maintenance overhead. All figures are fictional.
Simplified workflow illustration · no live systems connected
THE PROBLEM.
Imagine 180 processor-utilisation tickets per month, including brief scheduled update activity and transient application spikes. Assume four minutes of handling each. Raising the threshold alone could hide genuinely unhealthy devices.
HOW I WOULD APPROACH IT.
This hypothetical workflow shows how I would investigate noisy CPU alerts. It is an example of the service approach, not a claim that I delivered these numerical results for a customer.
THE PROPOSED WORKFLOW.
Audit the pattern and agree the signal
Review duration, repeat devices, top processes and scheduled work. Agree sustained-condition and recovery criteria, with separate handling for critical workloads.
Develop and test the monitor
Collect useful process context, check persistence and prevent duplicate incidents. Test short spikes, sustained load and recovery. Pilot changes on representative devices before staged implementation.
Monitor the exceptions and report
Review sustained incidents, repeat offenders and any missed problems with engineers. Report ticket quality alongside performance trends rather than celebrating a lower count alone.
MAKE IT TRUSTWORTHY.
Check that temporary activity recovers without an unnecessary ticket, while sustained load still escalates. Avoid automatic process termination; an engineer reviews unknown or business-critical processes.
Controls that matter
- Persistence and recovery criteria
- Critical-workload exceptions
- Collect diagnostic context
- Do not automatically kill processes
- Review false negatives
WHY IT MATTERS.
A fictional reduction from 180 to 45 tickets per month, at an assumed four minutes each, represents nine hours less handling before maintenance. The improvement is only useful if sustained performance incidents still receive attention.
MEASURE THE DURATION. UNDERSTAND THE PROCESS.
Site-level EDFs and service-driven onboarding
GOT SOMETHING
WORTH AUTOMATING?
Tell me where your RMM is creating work.
Let’s look at what could run better —
and how to get there.