CPU spike above threshold

High CPU is only a problem when work is waiting, and the busiest process is not always the one to stop. 2501 finds the process responsible, confirms it is the cause rather than a symptom, and brings usage back to normal, all within limits you set.

An alert fires on a threshold. The obvious move is to stop the top process, which is right about as often as it is wrong. It may be genuinely stuck. It may be doing expensive work it is meant to do. Or it may be busy because something it depends on is broken, and stopping it only hides the symptom.

What 2501 does

2501 identifies the process driving the load and confirms it is the cause rather than a symptom of a fault elsewhere, then remediates to bring usage back to normal. It reports what it found and what it did. The confirmation is what matters: acting on the top line of a process list is what a script does.

You stay in control

• You choose the level: investigate only, act after a person confirms, or act on its own within your rules. The level is set per specialty, not per ticket.
• Your rules apply: which processes are never stopped unattended, and the times when a person must approve.
• Some actions are never allowed: blacklisted commands and hosts stay out of reach, whatever a ticket asks for.
• Every job is bounded: an agent cannot keep working indefinitely on a host that keeps spiking.

Frequently asked

Is high CPU always a problem? No. A busy host is a working host. What matters is whether work is queuing and anything is slowing down.

Should I stop the process using the most CPU? Only once you know it is the cause. If it is doing legitimate work, or is busy because a dependency is down, stopping it makes things worse.

Can it diagnose without stopping anything? Yes. In investigate-only mode it reports the root cause and stops nothing.

Related

• SysOps
• Guardrails: what an agent may never touch