A high CPU number is a symptom, not a diagnosis. It might reflect useful traffic, a repeated application task, a backup job or unexpected activity. Start by identifying the process and the customer-visible effect. The workflow below uses read-only observations so you can preserve evidence before deciding what to change.
Confirm what is high
Record when the symptom began and which customers are affected. Compare actual CPU usage, load average, response time and errors. Load average is not a direct percentage and can include waiting work, so a large number alone does not prove a CPU shortage.
Check whether the machine has just started a scheduled job or completed a service change. A brief spike and sustained pressure need different responses. Use more than one sample; an idle screenshot taken after the complaint may miss the incident entirely.
Find the consuming process
List processes ordered by CPU, then inspect an identified PID with its parent and elapsed time. Replace 12345 with the PID you are authorized to investigate. Command lines may contain private values, so do not post raw output publicly.
Interpret the process in context. A PHP worker, database process and compression task have different responsibilities. The Unix owner can help scope an investigation, but a shared database process needs additional application or query evidence before assigning it to a tenant.
ps -eo user,pid,ppid,pcpu,pmem,etime,comm --sort=-pcpu | head -n 20
ps -p 12345 -o user,pid,ppid,etime,commTrace the workload rather than guessing
For PHP pressure, compare the affected account’s activity with application logs and recent changes. Repeated uncached endpoints, imports and background jobs are possible causes. For database pressure, inspect an authorized connection/query view and explain the query before changing a database-wide setting.
Do not call unexpected activity malicious solely from CPU use. Preserve logs and inspect relevant access patterns within privacy and access rules. A backup or legitimate scheduled task can resemble an incident when its purpose is not recorded.
Choose a bounded response
If a known scheduled job overlaps with peak traffic, review its timing. If one application path repeats expensive work, investigate caching, query behavior or the underlying dependency. If useful traffic genuinely exceeds measured capacity, adjust the resource plan.
Avoid restarting shared services as a first diagnostic action. It interrupts unrelated customers and may erase process evidence. Where intervention is necessary, scope it to the identified workload and use the documented administrative procedure with a recovery path.
Verify the original customer symptom
Repeat the request or authorized operation that was slow. Compare latency, errors and process demand across several samples. Check neighboring accounts so a local improvement does not hide a shared problem.
Record the finding and approved change. In EzePanel, Server Health and account resource policy provide useful context, but interpret missing measurements honestly. A lower CPU graph alone is not proof of recovery if the application still cannot serve or write data.
Where to go next
Sources & further reading
Official documentation for the topics in this guide. Check current vendor requirements before a purchase or server change.
