Reading your resource usage and knowing when a site is throttled

Before you decide a site is slow, read what it is actually consuming. Resource usage on a CloudLinux account is measured continuously and shown as faults against each limit, and a fault count of zero rules out the entire category of problem in one glance.

Where the numbers live

The control panel exposes a resource usage view for the account. It reports current usage and, more usefully, a fault count per limit over a chosen window. A fault means the account reached that ceiling and was held there. Usage graphs tell you how close you run; fault counts tell you how often you actually hit the wall.

Read them in that order. A site at 80 percent of its CPU allowance with zero faults is healthy and busy. A site averaging 20 percent with a hundred CPU faults is spiking hard and briefly, which is a completely different problem with a completely different fix.

Reading a fault pattern

• Faults clustered at the same hour daily: a cron job, a scheduled import or a backup. Move it or stagger it.
• Faults tracking traffic: genuine load. Cache first, resize second.
• Faults with no traffic at all: something is running on its own. Bots, a stuck process, or a plugin doing background work on every page load.
• Memory faults only: usually one specific operation, not general load. Find the operation.

The average hides the answer

Both accounts above would report a modest average. Only one of them has a problem, and it is the one with the lower average. This is why a monthly usage percentage is close to useless as a diagnostic and why fault counts are the number to watch.

What to do once you have found it

1. Cache before anything else. On a content site, server level caching removes most dynamic requests and with them most CPU and entry process pressure. Nothing else you do is as cheap.
2. Move scheduled work off peak. If three sites in one account back up at the same minute, stagger them.
3. Cut background chatter. Plugins that phone home, poll, or write to the database on every request are a common cause of faults on sites with almost no traffic.
4. Then resize. If faults persist with caching in place and nothing running in the background, the workload is genuinely larger than the plan.

Reading it across a network

With many accounts, look for the outlier rather than the total. One account generating faults while the rest sit quiet is a site problem. Every account generating faults at once is usually you, doing something to all of them at the same time, such as an update sweep or a bulk crawl of your own network.

The vendor reference at docs.cloudlinux.com documents each counter. When you have ruled out limits and the site is still slow, work through Diagnostics, and if the workload really has outgrown a shared account, compare it against a VPS with reserved resources.