Understanding Your StackCP CDN Statistics Dashboard

Once you've enabled Edge Caching and Web Optimisation (covered in our earlier guides), StackCP gives you a Statistics dashboard to see the real impact — how much of your traffic is being served from the cache, how much bandwidth that's saving, and how your requests break down by security and success rate.

One thing worth knowing upfront: CDN Statistics and Traffic Distribution are two views of the same screen, not separate features — you'll see a toggle to switch between them. This guide covers the main Statistics overview; our companion guide covers the Traffic Distribution (geographic) view specifically.

Why Look at This Dashboard at All?

• Confirm caching is actually working for your specific site.
• See how much bandwidth and load you're saving on your origin server.
• Spot problems early — a rising error rate or unusually low percentage of secure (HTTPS) requests are both things worth catching quickly.

Step 1: Where to Find It

1. Log in to your StackCP account.
2. Go to Manage Hosting, then Manage on the package you want to check.
3. Select Statistics.

You'll land on the CDN Statistics overview, with an option to switch to the Traffic Distribution view.

Step 2: Understanding Total Bandwidth

This section shows the total amount of data (in bytes) sent through the CDN to visitors, split into:

• Cached Bandwidth — data served directly from the CDN cache, without hitting your origin server.
• Uncached Bandwidth — data served directly from your origin (backend) server.

A higher proportion of cached bandwidth generally means your caching setup is doing more of the work, reducing load on your actual hosting account.

Step 3: Understanding Total Hits

This shows the total number of requests captured by the CDN network, similarly split into:

• Cached Hits — requests served from the CDN cache.
• Uncached Hits — requests served directly from your backend server.

Important distinction: "Hits" here refers to individual file and session requests captured at the network level — it is not the same as "unique visitors." A single page view can generate many hits (one for the HTML, more for each image, script, and stylesheet).

You can filter all of this by time period using the toggles at the top-right of each section.

Step 4: SSL Hits vs Non-SSL Hits

This chart shows how many requests to your site arrive over secure HTTPS versus unencrypted HTTP. Ideally, this should be overwhelmingly (ideally entirely) HTTPS. If you're seeing a meaningful number of non-SSL requests:

• Confirm you have an SSL certificate installed and active for the domain (see our SSL/TLS guide).
• Set up a redirect from HTTP to HTTPS, which can typically be done via a 301 redirect, a WordPress setting, or by ensuring your WordPress site/home URL are both set to the HTTPS version.

Step 5: Successful Requests vs Error Requests

This chart splits your traffic into:

• Successful Requests — any HTTP response in the 200–399 range, including standard "200 OK" responses and redirects.
• Error Requests — any response of 400 or above, such as "404 Not Found" or "503 Internal Server Error."

You want successful requests maximised. If you notice a rising share of error requests, that's your cue to check your access and error logs (covered in a separate guide) for details on exactly what's failing and why.

Understanding Why These Numbers Might Differ From Google Analytics

It's common — and entirely normal — for the traffic figures shown here to differ from what Google Analytics reports for the same site. There are a couple of specific, documented reasons:

• our platform's statistics reflect all HTTP traffic captured at the network level, including bots, crawlers, and automated requests, since these are counted regardless of whether they execute JavaScript.
• Google Analytics relies on JavaScript running in the visitor's browser to record a visit, meaning bots and non-JavaScript-executing crawlers typically aren't counted there at all.
• Hostname matching — once a unique hostname is identified for a request, it's matched against all registered server aliases for that domain, which can mean the request counts shown here are higher than other analytics tools report for the same traffic.

Neither number is "wrong" — they're measuring different things. CDN Statistics gives you a closer picture of total server-level load and delivery performance; Google Analytics gives you a closer picture of actual human visitor behaviour.

What a Healthy Dashboard Looks Like Over Time

For most small business sites, a reasonable pattern after properly enabling Edge Caching looks like:

• The first few days: Cached hits start low, since the cache hasn't had time to "warm up" with copies of your popular pages yet.
• Following weeks: The proportion of cached hits and bandwidth climbs as more of your content accumulates valid cached copies.
• Ongoing: SSL hits should sit close to 100%, and error requests should remain a small minority of total traffic.

If cached hits never climb, or error requests stay persistently high, that's worth investigating — the first via your Edge Caching configuration, the second via your access/error logs.

Common Mistakes Beginners Make

• Checking the dashboard too soon after enabling caching and concluding it isn't working, when the cache simply hasn't warmed up yet.
• Comparing these numbers directly to Google Analytics without accounting for the fact that they measure genuinely different things (all HTTP traffic vs. JavaScript-executing visitors).
• Ignoring a rising Error Requests trend until a customer reports a problem, rather than catching it proactively from the dashboard.

Troubleshooting

"My cached hits percentage seems low." Check that Edge Caching is genuinely enabled for the package, and give it time — a freshly enabled cache starts empty and improves as pages are requested repeatedly over the following days.

"I'm seeing a high number of non-SSL requests." Confirm your SSL certificate is active and that HTTP-to-HTTPS redirection is properly configured — see our SSL/TLS certificate guide.

"My error requests seem high." Cross-reference with your access/error logs to identify exactly which URLs are generating errors and why.

Using This Data When Something Feels Wrong

If a customer reports "the site feels slow" or "something's broken," this dashboard is often a faster first stop than guessing. A rising Error Requests trend points you toward the access/error logs for specifics. A drop in SSL hits points toward a certificate or redirect issue. A sudden change in cached vs. uncached ratio can indicate a configuration change (intentional or not) worth reviewing. Rather than starting from scratch every time an issue is reported, a quick glance here often narrows down where to look next.

Sharing This With a Developer or Agency

If you ever bring in outside help for performance work, this dashboard is usually one of the first things they'll want to see, since it gives an objective, network-level read on caching effectiveness and error rates without needing to run separate diagnostics. A quick screenshot of your bandwidth split, hit ratio, and error-rate trend over the last 30 days can save real back-and-forth time in an initial consultation.

A Worked Example: What "Hits" Actually Means in Practice

It's easy to misread "Total Hits" as "number of visitors," so it's worth walking through a concrete example. Imagine a single visitor loads your homepage, which contains the HTML page itself, five images, one CSS stylesheet, and two JavaScript files. That one page view generates roughly nine separate hits — one per file requested — not one. This is exactly why Total Hits figures can look surprisingly large compared to what you might expect from your actual visitor numbers, and why cross-referencing with a visitor-focused tool like Google Analytics (which counts sessions and users rather than individual file requests) gives you a more complete picture together than either figure alone.

Monitoring Statistics Across Multiple Customer Packages

If you're managing hosting for multiple customers, checking this dashboard individually for each package can become time-consuming. It's worth building a habit of periodically checking the packages that matter most — high-traffic customer sites, or any site where a customer has recently reported an issue — rather than attempting to review every single package on the same schedule. Prioritising your attention this way keeps the habit sustainable as your customer base grows.