CPU usage at your plan limit: caching, bots and cron jobs that bring it down

cPanel & WHM·· 7 views· 7 min read

The short answer: when the CPU graph in Resource Usage runs along the limit line, three levers solve most cases, in this order: page caching (PHP stops running on every visit), bots (you stop serving pages to visitors who never buy) and cron jobs (you stop repeating work for nothing). What burns CPU in general is in what eats CPU on a website. This article is the next step: the order to bring usage down this week, how to check it came down, and when an upgrade is the right answer.

What the graph is telling you

What you see in Resource Usage What it usually is Where to start
High CPU all day, rising and falling with visits Pages built from scratch on every visit: there is no cache, or the cache is not catching the pages Caching
Spikes at set times (on the hour, at midnight, always at the same minutes) A cron job, a backup, a report or a sync with another service Cron jobs
Spikes with no pattern, at night too, with few people on the site Bots walking the site: search engines, price scrapers, SEO tools, AI crawlers Bots
High CPU only while someone works in the WordPress dashboard The editor left open calling the server, admin-ajax, a heavy plugin in the dashboard. See admin-ajax eating your resources WordPress dashboard
Spikes when you launch a campaign or post on social media Real people. If the pages are not cached, every visit is expensive Caching; if you already have it, see «Optimise or upgrade?»

Bringing CPU down, in this order

1 Look at the «when» first. In cPanel, open Resource Usage, pick the last week and look at the CPU graph. Write down the days and hours of the faults, the moments the account hit the limit. Without that you are guessing.
2 Switch caching on and check it works. On a WordPress site, the right plugin on our servers is LiteSpeed Cache: LiteSpeed Cache for WordPress. Then open a page in a private window, press F12, go to the Network tab and look at the response headers: with caching working you see x-litespeed-cache: hit from the second visit on. If it is not there, caching is switched on but not serving.
3 Find out who is asking for pages. Under Metrics > Raw Access, or in the visitor statistics, see which addresses and which bot names make the most requests. AI crawlers: ask them to stay out, or refuse them by name, as in AI bots crawling your site. An address that lies about who it is: blocking an IP address. Lots of requests to wp-login.php or xmlrpc.php are break-in attempts, not visits.
4 Review your cron jobs. In cPanel, open Cron Jobs and ask of each one: does it really need to run this often? A job that runs every minute is often just as useful every 15 minutes or every hour. Move the heavy ones (backups, reports, imports) to a quiet hour.
5 In WordPress, swap WP-Cron for a server cron job. The internal tasks then stop firing on every visit: swapping WP-Cron for a real server cron job.
6 Measure again. Let a few ordinary days go by and compare the CPU graph at the same hours. Change one thing at a time, so you know which one worked.

Optimise or upgrade?

Situation Optimise or upgrade?
There is no cache, or the cache is on but not serving the pages Optimise. It is the biggest saving, and it costs nothing.
Most requests come from bots or break-in attempts Optimise. Refuse or filter them: a bigger plan would only give them more to burn.
The spikes line up with cron jobs or backups Optimise. Space them out or move them to another hour.
Only one page is slow (search, filters, reports) Optimise that page. An upgrade will not make it faster: slow queries.
Caching works, bots are under control, crons reviewed, and the faults still come at your busiest hours Upgrade. The site has grown, which is good news.
You need CPU of your own, always available, for heavy and continuous work VPS or Cloud. See shared hosting vs VPS.

Bigger plans

CPU is counted in processor cores: 100% is one whole core. Pro and Plus have 1 core, Ultra and Business Pro 2, Business Plus 3 and Business Ultra 4 (table below). Note that from Pro to Plus, and from Ultra to Business Pro, the CPU does not change: if CPU is what is at the limit, the right upgrade is to a plan with more cores. In Resource Usage, the limit line shows your account’s value. If the site is already optimised and keeps running into the limit, upgrade in Meu Interweb: you pay only the difference until renewal, and the site, the e-mail and the files stay where they are. The steps are in how to upgrade your plan, and which plan comes after yours in which hosting plan comes next.

Plan CPU
Pro 100% (1 core)
Plus 100% (1 core)
Ultra 200% (2 cores)
Business Pro 200% (2 cores)
Business Plus 300% (3 cores)
Business Ultra 400% (4 cores)

Our warnings: when the account reaches 75%, 85% and 95% of the limit of a plan resource, you get an e-mail with every resource on the account, each with its limit and the percentage you use, and the upgrade plans (between 75 and 85%, every 15 days; between 85 and 95%, every 7 days; from 95%, every 3 days). If several resources are close to the limit, they all come in the same e-mail. The limit is 100%. Above it the account may be suspended, and we always warn you the day before. To bring it back, upgrade (the account reactivates by itself straight after) or ask for 24 hours to sort it out from the link in the e-mail: the account stays active for 24 hours and, if it is still over the limit at the end, it is suspended again straight away (you can ask for the 24 hours once every 7 days). If usage drops back below the limit, the account becomes active again by itself. What each warning means is in usage warnings at 75%, 85% and 95%.

Do not block Googlebot or the search engines that bring you customers. Blocking bots by name without reading the list can take the site out of search results. Before touching .htaccess, keep a copy of it: one typo puts the whole site on error 500.
The robots.txt Crawl-delay does not work for everyone. Some engines respect it; Google ignores it and sets its own pace. For bots that respect nothing, only refusing them on the server or a filter in front of the site, such as Cloudflare, works.

Not sure what is burning CPU? Tell us the domain and the times of the faults, and we will look at the logs with you.

Open a support ticket

SEE ALSO

What eats CPU on a website, and how to bring it down

LiteSpeed Cache for WordPress: the first settings

AI bots crawling your site: robots.txt and how to block them

Swapping WP-Cron for a real server cron job

Hitting the entry processes limit often: when to optimise and when to upgrade

How to upgrade or downgrade your plan

RECOMMENDED PRODUCT

Web hosting with cPanel

Domain and SSL included, daily backups and the panel you already know. from $6.59/mo (3-year plan, with coupon)

See plans
Was this answer helpful? Your answer helps us improve this article.