Here is a story for you.<\/p>\n\n\n\n
Diego runs a 30-account VPS for small business clients. At 4 a.m., the server is nearly asleep: one cron job, a trickle of visitors, seven idle cores. A backup script on one account wants to compress a large archive, and under a strict CPU limit, it crawls at half a core while the other seven cores just sit idle. <\/p>\n\n\n\n
Why throttle a job when no one needs protecting from it? <\/p>\n\n\n\n
Burst mode<\/strong> is SPanel’s answer, and it captures how we think about limits: they protect everyone on the server, not punish paying customers.<\/p>\n\n\n\n Burst mode makes per-account resource limits load-aware, so they stand down when the server has spare capacity and engage the moment it doesn’t.<\/p>\n\n\n\n SPanel enforces five per-account limits<\/strong> through Linux control groups (cgroups v2, the same kernel mechanism the container world is built on):<\/strong> <\/p>\n\n\n\n A small SPanel service sweeps once per second and places each limited account’s processes into its control group. Burst mode decides when<\/em> that machinery clamps down, server-wide.<\/p>\n\n\n\n With burst mode on, the service compares the server’s load against the CPU core count every second: below the count, accounts run unconfined and use the spare capacity; at or above it, every limited account is confined to its budget. Full speed on a quiet server, fair shares on a busy one. <\/p>\n\n\n\n Every admin who has set a CPU limit knows the feeling: you cap an account so a runaway plugin can’t take the box down, then watch it get throttled at 2 a.m. on a 90%-idle server, slowing a paying customer for no benefit. A limit only earns its keep during the busy windows when accounts contend for the CPU. Burst mode acts then and gets out of the way the rest of the time.<\/p>\n\n\n\n Limits should protect everyone, not punish anyone<\/strong> – a principle that runs through all of SPanel’s kernel-level resource controls, not just burst mode. SPanel’s package limits reference covers every dial and what happens when an account reaches it.<\/p>\n\n\n\n First, the number that trips people up. A CPU limit in SPanel is a percentage of a single core, not of the whole server<\/strong>: 100% means one full core, 50% means half a core, 200% means two cores. Admins coming from other systems often misread “100” as the entire machine.<\/p>\n\n\n\n The trigger itself is not a per-account percentage. <\/p>\n\n\n\n It is system load compared against the core count. On an 8-core server, a load average below 8 means roughly one core’s worth of capacity is idle, and SPanel reads that as room to spare; at 8 or higher, every core is spoken for and accounts go back inside their budgets. It is a deliberately blunt signal, cheap to measure. <\/p>\n\n\n\n Two details matter, and skipping either would oversell the feature.<\/p>\n\n\n\n Both postures are legitimate; which one a server should run is a deliberate decision, not a default to accept blindly.<\/p>\n\n\n\nWhat burst mode actually is<\/strong><\/h2>\n\n\n\n
\n
The objection burst mode answers<\/strong><\/h2>\n\n\n\n
How the trigger works: load versus core count<\/strong><\/h2>\n\n\n\n
The one-second sweep, told honestly<\/strong><\/h2>\n\n\n\n
\n
Burst mode on or off: which posture fits your billing<\/strong><\/h2>\n\n\n\n
![\"Burst](\"https:\/\/www.scalahosting.com\/kb\/wp-content\/uploads\/2026\/09\/01-server-settings-1024x640.webp\")
<\/figure>\n\n\n\n![\"Burst](\"https:\/\/www.scalahosting.com\/kb\/wp-content\/uploads\/2026\/09\/02-cpu-limit-package-form-1024x640.webp\")
<\/figure>\n\n\n\n![\"Burst](\"https:\/\/www.scalahosting.com\/kb\/wp-content\/uploads\/2026\/09\/03-change-limits-1024x640.webp\")
<\/figure>\n\n\n\n