Guide to Interpreting Host Resource Usage Charts and Finding Resource-Heavy Scripts

Your site won't open or has become slow, you've submitted a ticket, and the response says "your host resource usage has exceeded the allowed limit." Now you're staring at a chart with a few colored lines and numbers, none of which make any clear sense. This article is for exactly that moment: reading that chart and getting from the number to the line of code.

First, a point that throws many people off track: on shared hosting, CPU is not "dedicated" to you. You have a share of a shared processor, and the host controls it with two mechanisms; one is the instantaneous usage ceiling (usually measured as a CPU percentage over short intervals), and the other is the concurrent process count ceiling, or entry process. The first number tells you how fast you're running, the second tells you how many people can enter at the same time. Don't confuse these two, because their remedies are completely different.

How to Read the CPU Chart Without Being Misled

Don't look at the peak, look at the shape of the chart. In practice, I see three patterns:

• Narrow, frequent peaks: A specific script runs at regular intervals. It's almost always a cron or an AJAX request that the browser sends every few seconds.
• A high, flat level for hours: This isn't real traffic, it's a loop. A script stuck within itself, constantly hammering the database.
• Stepped and coinciding with specific hours: Human traffic. If it rises every day from 10 to 12, the problem is capacity, not a bug.

A real number I see often: a site with 400 daily visits whose CPU chart hits 90 percent every night at 3 AM and stays there for 20 minutes. There's no visitor, no attack. It's a backup of a 1.2-gigabyte database on the same host, without --single-transaction, which locks the tables and brings everything down until it finishes.

The Difference Between CPU and Entry Process in Practice

If the entry process is full, the user sees the 508 Resource Limit Is Reached error or gets a white page, but the CPU may be low. This state means requests have piled up on top of each other and each is waiting for something; usually a slow external request (a payment gateway API, an SMS web service) or a heavy query that takes 30 seconds to respond. The opposite also happens: CPU is locked at 100 percent but the site opens, because only one process is frantically busy.

Finding the Resource-Heavy Script with Tools Available Right Now

First of all, look for the access log file from the host panel. If you have SSH access, these two commands are the fastest way to reach the culprit:

awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -20

This line tells you which paths received the most requests. If wp-cron.php or admin-ajax.php is at the top of the list, the problem isn't traffic, it's the site itself. The second command ties usage to a time range:

grep "admin-ajax.php" access.log | awk '{print $4}' | cut -d: -f2 | sort | uniq -c

The output of this command shows the hourly distribution. If all requests are concentrated in one minute, you have a loop in JavaScript or a faulty cron.

For queries, if MySQL is accessible, run SHOW FULL PROCESSLIST; twice with a few seconds in between. A query that appears in both outputs is the bottleneck. In WordPress, a plugin that logs queries usually creates usage itself; turn it on for just a few minutes and then turn it off.

To check whether the problem is network or DNS and the slowness is from the server side, DNS and network lookup is a good starting point; if TTFB is high but DNS resolves quickly, the issue is entirely internal.

Take Crons Seriously

Half of the cases referred to me are a cron that someone forgot about. Use crontab -l to see the list and ask for each line when it was last needed. If you don't remember the five-field syntax exactly, open the complete cron syntax reference; a wrong * in the minute field runs a heavy script every minute and you think you've been hacked.

Here's where people make a mistake: the user sees the chart, quickly installs a caching plugin, and says it's fixed. Two days later the same peak returns, this time worse. Caching only reduces the number of PHP executions; if the culprit script is a cron or a background process, caching has no effect on it and only hides the problem until you exceed the limit again. The sign is this: CPU usage drops a bit after installing caching, but the nightly peaks stay right where they were.

Which Solution to Choose

There are three real paths, and choosing between them depends on whether you've found the culprit or not.

If you ask me, in 80 percent of cases the first row is the answer, and upgrading the plan only changes the appearance of the problem. But I have one condition: if after fixing the culprit, the site's baseline usage (without traffic) is still above 30 percent of your share, optimization is no longer useful and you must increase resources. That 30 percent isn't an arbitrary number; it's the margin you need for traffic peaks and nightly backups.

Another trap: some people move the database to another server to escape the limit. If the network between the two servers has latency, every query becomes a few milliseconds slower, and on a page with 200 queries, that means several seconds. The result is that CPU drops but the entry process fills up, because each process stays open longer.

Practical Tasks You Can Do Today

1. Download the access log for the past 24 hours and run the two commands above.
2. Get the list of crons with crontab -l and from within the panel, and disable any line whose purpose you don't know.
3. Deactivate plugins one by one and check the chart 10 minutes after each. This is tedious but it's the most definitive method.
4. If you're getting database errors and have a heavy SQL file, replace the simple import with the importing a large SQL file without timeout method; an incomplete import is one of the common causes of sustained high usage.
5. For server rules and redirects, see the htaccess directives reference; a redirect loop can generate infinite requests.

If the site runs on WordPress and you have many plugins, first of all check the list of installed PHP extensions; sometimes a plugin takes a slower path due to a missing module. The list of PHP extensions and how to test them clarifies this.

And if you're just about to set up a site from scratch on a stable foundation, Linux hosting with full access to logs and cron makes exactly the tasks we discussed in this article possible; without logs, identifying the culprit is guesswork.

Frequently Asked Questions

Why does my host's CPU usage go up at night when there are no visitors?

It's almost always a cron or a backup process. Check the crons with crontab -l and from the host panel, and see which one runs at that hour. Database backups without table locking and WordPress's automatic optimization are two common nightly culprits.

Does the 508 Resource Limit Is Reached error mean the CPU is exhausted or something else?

This error is usually related to the entry process ceiling, not CPU. It means your concurrent process count is full and a new request has nowhere to sit. The sign is that the site opens for some users and not for others, while the CPU chart is low.

Does installing a caching plugin solve the host resource usage problem?

Only if the culprit is repeated PHP execution for repeat visitors. If the culprit is a cron, a heavy query, or a slow external request, caching has no effect on it and only delays the peaks. Find the culprit first, then add caching.

How do I know whether I should upgrade the plan or just optimize the code?

Measure the site's baseline usage at an hour when traffic is zero. If after removing crons and extra plugins it's still above 30 percent of your share, further optimization won't help and it's time to upgrade. If it's lower, the problem is the code, not capacity.