Measurement lab · Beginner · 20 min
Reading Your Statistics as a Load Report
You want to know which URLs are consuming the account's CPU allowance, not how many sessions bounced — and that answer lives in the raw log, not in analytics.
The short answer
Read server statistics as a record of work done, not of people visiting: every line in the raw access log is one request the machine actually served, with its URL, its status code and its byte count, which makes the log the only honest source for capacity questions.
Analytics answers a different question. It runs in the browser, counts humans who allowed the script, and tells you about journeys and conversions. The log counts everything — crawlers, scanners, asset requests, failed probes — and that is precisely why it is the file to open when the account is brushing its CPU ceiling.
By the HostingFast team · Reviewed 12 August 2026
Beginner
Reader level
20 minutes
Wall-clock time
5
Steps to done
24/7
Engineers on call
Twenty minutes gets you a genuine picture: top URLs by hits, the status distribution, the share that is automation, and a rough sense of what your cache is absorbing.
Everything here comes from cPanel's Metrics section and a handful of shell one-liners. SSH ships on every shared tier, so you can run these against the log rather than clicking through a summary.
Two tools, two different questions
The raw access log answers what did the server do. One line per request: client address, timestamp, method and path, status code, bytes sent, referrer, user agent. AWStats aggregates that same file into monthly tables. Neither knows anything about a session, a conversion or a person.
Analytics answers what did people do, and it does so by running JavaScript in browsers that permit it. The two numbers will never match, and expecting them to is the mistake that sends people looking for a bug. Use field data and analytics for behaviour and ranking questions; use the log when the question is about load.
Reading the log as capacity data
Start with volume by path. cut -d' ' -f7 access.log | sort | uniq -c | sort -rn | head -20 gives you the twenty URLs the server spent most of its time on. Then look at the status distribution: cut -d' ' -f9 access.log | sort | uniq -c | sort -rn. A large 404 bucket is wasted work; a rising 500 bucket is an incident you have not been told about yet.
Byte counts matter as much as hit counts. Field 10 is the response size, so cut -d' ' -f10 access.log | paste -sd+ - | bc totals what you actually shipped; divide by 1048576 for megabytes. A handful of unoptimised images can dominate that figure while contributing almost nothing to the hit count.
Separating machines from people, with numbers
AWStats has a robots and spiders section, and it is usually a revelation: a large share of what looks like traffic is search crawlers, uptime monitors, feed readers and vulnerability scanners. That is the entire reason analytics reports a smaller figure than your server stats, and neither number is wrong.
For a quick split from the shell, count the user agent field and eyeball the top entries: cut -d'"' -f6 access.log | sort | uniq -c | sort -rn | head. Anything requesting only /wp-login.php or old plugin paths is a scanner, and if it is generating real volume it belongs in a discussion about blocking rather than about traffic growth.
Where the log stops, and what to reach for next
The log tells you what was requested, not what it cost. For that, cPanel's Resource Usage page charts CPU, memory and entry processes against your allowance over time, which is the number that gets you throttled. On Nitro, PHP X-Ray on CloudLinux Pro attributes slow time to a specific URL and function rather than leaving you to infer it.
You can also infer cache effectiveness by comparing the log against your cache headers: requests for HTML that return quickly and never appear in the PHP slow log are being answered by LiteSpeed, not by your application. If your busiest paths are the ones bypassing the cache, that is the finding worth acting on.
The panel these numbers come out of
AWStats, raw access log downloads and Resource Usage all sit in the Metrics section of the cPanel we actually run, and the shell one-liners above were tested over SSH on a live account.
NVMe storage behind a LiteSpeed cache is standard on every tier, which is why so much of your HTML traffic never reaches PHP in the first place.
- Shell one-liners printed in full, ready to paste
- Log fields named by position, so the awk makes sense
- The bot share explained rather than hand-waved
- Round-the-clock engineers when the graph looks wrong
Why HostingFast
Standard on every plan
Load data, not vanity data
The page is built around the questions that decide whether your account stays inside its allowance.
Commands over screenshots
Six one-liners against the raw log answer more than an hour of clicking through summary tables.
The mismatch, explained once
Why AWStats and analytics will never agree, and why that is expected rather than a fault to chase.
Bytes as well as hits
The response-size field is where unoptimised images hide, and the guide shows you how to total it.
A path onward
When the log runs out of answers, Resource Usage and PHP X-Ray on CloudLinux Pro pick up the trail.
Help that reads the file
Support is staffed at every hour and will go through your access log with you rather than quoting an uptime figure.
Quick Start
From order to online
- 1
Get the raw file, not the summary
Metrics, then Raw Access, then download the current log or the archived gzip. Turn on archiving in the same screen if you want to keep more than the current rotation, because the default rotation is not a retention policy.
- 2
Rank the URLs, then the status codes
cut -d' ' -f7 access.log | sort | uniq -c | sort -rn | head -20, then the same against field 9. You now know where the work went and how much of it failed.
- 3
Subtract the automation before drawing conclusions
Count field 6 of the quote-delimited user agent and look at the top entries. A traffic spike that turns out to be one scanner is a security note, not a growth report.
- 4
Convert hits into server work
For each of your top paths, ask whether it is cacheable. A cached URL costs bytes and nothing else; an uncacheable one costs a PHP worker and a database round trip every single time.
- 5
Check the finding against Resource Usage
Open the CPU and entry-process graphs for the same period. If the busy hours in the log line up with the peaks on the graph, you have your culprit; if they do not, something uncacheable and infrequent is the real cost.
Built In
Loaded onto every plan
- AWStats plus raw access log downloads in cPanel's Metrics section
- Resource Usage graphs for CPU, memory and entry processes
- Full SSH access with Git and Composer on every shared plan
- LiteSpeed caching in the server, so cached HTML never reaches PHP
- NVMe SSD storage on every tier, not only the expensive ones
- Per-site PHP version switching from the control panel
- PHP X-Ray on CloudLinux Pro on the Nitro tier for slow-request attribution
- Human support around the clock, at no extra charge
- Money-back cover: 30 days on hosting plans, 7 on reseller
- Renewal at the price you first signed up at
Frequently Asked
What people ask us most often
Why does AWStats report far more traffic than my analytics?
Because they count different things. AWStats counts every request the server handled, including crawlers, uptime monitors, scanners and asset fetches. Analytics counts browser sessions where its JavaScript ran and was permitted to report. The gap is mostly automation, and AWStats has a robots section that will show you roughly how much. Neither figure is broken; they answer different questions.
Can I work out my cache hit ratio from the access log?
Not directly, because the log does not record whether LiteSpeed or PHP produced the response. You can get close by comparing the log's top HTML paths against a live header check: curl -sI on each of them, looking for x-litespeed-cache. If your busiest paths report a miss on a repeat request, you have found the most valuable thing in the file.
How long are raw logs kept, and can I keep my own copies?
cPanel rotates the raw log, so what you see is the current window rather than a permanent archive. In the Raw Access Logs screen you can switch on archiving so a copy is kept, and you can download the gzip files at any point. If logs matter to you for capacity planning, pull them on a cron job and keep them wherever you keep the rest of your operational data.
Do server statistics count as field data for Core Web Vitals?
No. Field data is collected in the browser from real Chrome users and covers rendering metrics such as LCP, CLS and INP — things the server never sees. The log can tell you that a URL is slow to first byte, which is one input into LCP, but the rest of the story happens after your response has left the machine.
Keep reading
How to Enable LiteSpeed Caching
Turn the cache on, then prove the hit from the response headers before tuning anything.
How to Set Up Domain Forwarding
Send one hostname somewhere else without pretending it is a hosted site.
DNS (Domain Name System) (Glossary)
How a name becomes an address, and which record answers which question.
Laravel Hosting
Laravel with the CLI, Composer and per-site PHP switching you would expect.
Domain Names
Registration, renewal and delegation, with your first year free on annual plans.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Hosting that shows you its own numbers.
AWStats, raw logs and Resource Usage graphs in cPanel, SSH on every plan, and engineers who will read the output with you at any hour.
View Laravel Hosting plans