Signs It's Time to Upgrade Your Server
%203.png&w=256&q=75){kind=small}
Sustained Load Average, Not a Snapshot
A single high load average reading proves nothing — the real signal is load average that stays above your core count for days or weeks at a time, not a spike that shows up once and disappears. Load average is a rolling measure of how many processes are running or waiting for CPU time, averaged over 1, 5, and 15 minutes, and it only becomes meaningful once you compare it against how many cores you actually have.
A 4-core box running a sustained load average near or above 4.0 for the 15-minute figure, day after day, is genuinely CPU-constrained. The same reading appearing once during a deploy or a backup job means nothing. A single `uptime` run cannot tell you which of these you are looking at — you need the trend over time, which is exactly what a one-off SSH check will never give you. CloudStick's dashboard graphs CPU, RAM, and disk over time using Zabbix Agent 2, so you can look at the last 7 or 30 days of load rather than a single moment and see whether the pressure is constant, growing, or only tied to specific events like backups or cron jobs.
Swap Usage and Disk Usage Trending Up
Swap that is consistently non-zero — not a brief spike during a backup, but a used figure that never returns to zero between checks — means RAM is genuinely insufficient for your working set. Disk climbing toward 80-90% with no further logs, old backups, or unused packages left to clean is the same category of problem: a resource ceiling that cleanup can no longer fix.
Run `vmstat 1 5` a few times across the day rather than once — repeated nonzero `si` (swap in) and `so` (swap out) values across multiple samples confirm the kernel is actively paging memory to disk, which is slow and a genuine sign of RAM pressure, not a one-off blip. For disk, check whether the growth is from something you can actually reclaim — old backup archives, rotated logs that never got compressed, stale Docker images — before concluding you need a bigger disk. If you have already deleted everything reclaimable and usage keeps climbing on its own, that is a real capacity signal.
PHP-FPM and MySQL Hitting Ceilings During Normal Traffic
PHP-FPM hitting its configured `pm.max_children` ceiling during ordinary, everyday traffic — not a launch day or a marketing spike — means the server cannot serve its normal request volume with the workers it has. The same logic applies to MariaDB: if the slow query log keeps filling up after you have already optimized the queries and added the right indexes, the database has run out of the CPU or I/O headroom needed to serve them fast, not a query design problem.
The key qualifier both times is "during normal traffic." Every stack hits its configured limits under a genuine spike — that is what limits are for. The signal you actually want is these ceilings getting hit on an ordinary Tuesday afternoon, repeatedly, over days. CloudStick's Web Application Logs surface these PHP-FPM and slow-query patterns per site without needing to SSH in and tail files manually, which makes it much faster to confirm whether a ceiling is being hit occasionally or constantly.
TTFB Creeping Up Over Weeks
Time to first byte that rises gradually over weeks, without any corresponding code deploy, plugin install, or traffic spike, points at capacity rather than a regression. A sudden jump right after a deploy is a code problem; a slow, steady climb with no obvious trigger is the server running out of headroom as data, users, or background jobs accumulate.
A single TTFB number tells you almost nothing on its own — you need a series measured the same way, at similar times of day, across several weeks. If that series is flat, whatever feels slow today is probably an isolated event. If it is climbing steadily alongside rising load average, nonzero swap, or a growing slow-query log, the pieces corroborate each other and point at the same conclusion: the server has less spare capacity than it used to.
False Signals That Don't Mean You Need a Bigger Server
A one-time traffic spike from a viral post or a single marketing email is not evidence you need more hardware — it is evidence your server briefly handled more load than usual, which is a different thing entirely. If load average and TTFB return to their normal baseline once the spike passes, the server did its job.
A single slow plugin or an unindexed query named specifically in your slow query log should be fixed or removed, not compensated for with a bigger server — throwing more CPU at a query missing an index just makes the same wasteful query run somewhat faster while still consuming resources it never needed to. Likewise, a misconfigured cache — an object cache like Redis that is not actually connected, a page cache that is disabled or bypassed on every request, static assets not offloaded to a CDN — should be fixed at the configuration level. Adding hardware on top of a broken cache just means you are paying more to mask a bug that is still there.
The Decision Rule: Optimize First, Upgrade Last
If you have not already tried caching, query optimization, and CDN or static-asset offloading, try those first — hardware is the last lever you pull, not the first. Each of those fixes typically buys back far more headroom per hour of work than a hardware upgrade does, and they fix the actual problem instead of paying to outrun it.
Before you resize a server, confirm three things: object caching (Redis) is actually connected and being hit, the slow queries named in your MySQL slow log have been optimized or indexed, and static assets and images are served from a CDN rather than PHP-FPM. If any of these has not been done yet, do it first — it is very common for a server that "needs upgrading" to be fine once these are addressed.
Once caching, query optimization, and offloading are genuinely in place, and the signals from the previous sections are still trending the wrong way over days or weeks — sustained load above core count, nonzero swap, disk with nothing left to reclaim, PHP-FPM or MySQL hitting ceilings on ordinary traffic, TTFB climbing with no code change — that is when a bigger server is the correct fix, not a workaround. CloudStick prices per server rather than per site, starting at $9/mo for a typical 4 vCPU / 8GB RAM / 150GB disk box, so resizing to the next tier up is a single decision rather than a per-site cost calculation, and the same dashboard trend graphs that told you it was time will confirm afterward that the new headroom actually holds.
