Explained
Your server's processor is pinned at 100% — what that actually means
Real server problems, translated into plain English by Onserva.
What you're seeing
A graph flat against the ceiling. Every refresh says 100%, or something close enough that the difference doesn't comfort you. Maybe the site feels sluggish; maybe it feels completely normal, which is somehow more unsettling. The instinct is that a number at its maximum must be an emergency.
What it actually means
Start here, because it reframes everything that follows: a processor at 100% is a processor being fully used, and that is what you are paying for. Unlike a disk filling or memory running out, there is no cliff at the top. Nothing breaks when a processor is busy. Work simply queues, and the queue is where the real story is.
So the headline percentage is close to useless on its own. Two other facts decide whether you have a problem:
- How long it has been there. Thirty seconds at 100% during a deploy is the machine doing exactly its job. Three hours at 100% on an ordinary afternoon is a different animal entirely. The duration, not the height, is the signal.
- Whether anything is waiting. Engineers call this the load average, and it is the more honest number: it counts the jobs queued up for a turn. A queue of 4 on a 4-core machine means everything is being served promptly. A queue of 16 on that same machine means work is arriving four times faster than it can be cleared, and every visitor is waiting.
A server at 100% with a short queue is efficient. A server at 60% with a queue ten deep is in trouble. This is why the percentage alone should never wake anybody.
The usual causes
- Real work, on a schedule. A build, a backup, a nightly import, an image resize queue. The giveaway is the clock: if the spike lands at the same time each day or night, you have found it. This is the most common answer and it needs no fixing.
- A runaway process. Something entered a loop it cannot leave — a stuck worker, a job retrying forever, a pattern-match on hostile input. The signature is a flat line with no relationship to traffic: it does not fall at 3am, because it is not responding to anybody.
- More workers than cores. A configuration copied from a bigger machine, asking a 2-core box to run twelve parallel workers. They do not go faster by being more numerous; they take turns, and the turn-taking itself costs time.
- You have simply outgrown the box. The least dramatic cause and often the true one. Traffic grew gradually, nothing broke, and the machine has been quietly at its limit for weeks. The tell is a ceiling that got closer over months rather than appearing on a Tuesday.
- Someone else's server. On cheaper shared hosting your machine can be made to wait for a physical processor that a neighbour is monopolising. Your own graphs look busy while your own software is doing very little — a frustrating case, because the fix is a different plan or a different provider, not a change to your code.
What to do now
- Look at the shape, not the value. Widen the graph to a week. A daily sawtooth is scheduled work. A step that began on one specific day points at a deploy or a change you can name. A slow climb over months is capacity.
- Compare the queue against your core count. If the queue is comfortably below the number of cores, your server is busy and fine — you can stop here, whatever the percentage says.
- Find out which process, and whether it is one or many. One process pinned at 100% is a runaway. Many processes each taking a share is genuine load. These two look identical on a single overall graph and need opposite responses.
- Rule out the disk before blaming the processor. A machine that appears busy while waiting on slow storage is a common misdiagnosis — it is measured separately, and it explains the “slow but nothing looks busy” complaint far more often than a genuinely overloaded processor does.
- Resist restarting it. A restart will clear a runaway and destroy the evidence that identifies it, and the runaway will be back. If you can afford ten minutes, spend them finding out what is looping first.
When to worry
Worry when the queue stays above your core count for a sustained stretch, because that is the point at which the number stops being trivia and starts being your visitors waiting. Worry when a flat line has no relationship to traffic — that is a runaway, and it is burning capacity you are paying for and will need during your next busy hour.
Do not worry about spikes. A server that touches 100% during a deploy, a backup or a genuine rush of customers is behaving correctly. Treating those as incidents is how teams learn to ignore their own alerts — and an alert everyone ignores is worse than no alert at all, because it is still there when something real happens.
The quiet version worth catching: a machine that used to peak at 60% and now peaks at 95%. Nothing is broken and nothing will page anyone, but you have spent your headroom. The next unusual day — a campaign, a busy Monday, a slow database — is the one that tips it over, and by then the only fast fix costs money.
How Onserva handles this
Onserva deliberately does not alert on a spike. Every reading is judged on a sustained average rather than the latest sample, because a server briefly at 100% is a server doing its job, and waking you for it would teach you to ignore the alerts that matter. It judges the queue against your machine's actual core count, so “busy” means the same thing on a one-core box and a thirty-two-core one. Time spent waiting on the disk is tracked as its own figure, so the “slow but nothing looks busy” case is distinguishable rather than guessed at. And it watches each container's own share, which is how a runaway gets a name instead of just a graph.