Reading the Web Traffic Graphs

The Web Traffic panel on the CorePanel dashboard shows what your web server is doing, minute by minute, over the last 3 hours. The data is measured inside the web server itself (CoreHttpd) as it serves every request — it is not an estimate, a log sample, or an external probe.

A few basics before diving in:

• Every bar and every point is one minute of traffic.
• The 30M / 1H / 3H toggle changes the visible window; the server always keeps the full 180 minutes.
• The panel refreshes automatically every minute. Times are shown in your browser’s time zone.
• Hover any minute to get exact values for every series.

Requests per minute

The top chart counts every request the server finished in each minute — all methods, all outcomes. The height of a bar is your traffic volume; the colors split it by HTTP response class:

Color	Class	What it means
Green	2xx success	The request was served correctly. This should dominate every bar.
Blue	3xx redirects	The server answered with a redirect (e.g. http → https, moved pages) or a 304 Not Modified cache revalidation. A steady share is normal.
Amber	4xx client errors	The client asked for something the server can’t serve: missing pages (404), forbidden paths (403), bad requests.
Red	5xx server errors	The server (usually a site’s application code) failed to produce a response. This is the color to watch.

What to look for

• Mostly green with thin blue/amber caps — healthy. Every real site gets a trickle of 404s and redirects.
• A red band appears — some site is throwing errors (crashing PHP, a broken plugin or theme update, an unreachable database). Check the affected site’s error output around that time; the latency chart below usually tells the same story.
• An amber flood — a burst of 404/403 is almost always bots and vulnerability scanners probing paths like /wp-admin or /.env, or a deployed site with broken internal links. Scanners are background noise on any public server; a sustained wall of amber is worth a look at the access logs.
• Rising blue — often harmless (cache revalidations from returning visitors), but a sudden jump can indicate a redirect loop on a site.
• A sudden cliff or spike in total height — traffic itself changed: a campaign, a viral link, or a bot wave. Height alone isn’t a problem; check whether latency held steady while it happened.

Latency — successful responses

The bottom chart answers a different question: how fast were pages served? It shows three latency percentiles for each minute, in milliseconds:

• p50 (median) — half of all responses were faster than this. This is the typical visitor experience.
• p95 — 95% of responses were faster than this. This is your slow tail: the experience of the unluckiest 1-in-20 requests.
• p99 — 99% were faster. Your worst case, short of outliers.

A useful mental model: p50 is what most visitors feel, p95/p99 is what your slowest pages and heaviest queries feel. A large gap between p50 and p99 is normal on a hosting server — cached static files are served in under a millisecond while a heavy WordPress page might take a second.

What gets measured — and what deliberately doesn’t

Percentiles are computed only from successful content responses (GET/HEAD requests answered with 2xx). This is intentional:

• Uploads (POST/PUT) are excluded — their duration mostly measures the visitor’s upload bandwidth, not your server. One 20 MB upload on mobile data would look like a 40-second “slow request” on a perfectly healthy box.
• Redirects and 304s are excluded — they complete in microseconds and would drag the percentiles down, making the server look faster than pages actually load.
• Errors are excluded — a fast 500 is not good news, and a bot flood of instant 404s would “improve” your latency while a site is broken.

Error visibility lives in the requests chart above; the latency chart stays an honest measure of page-serving speed.

What to look for

• Flat, low p50 with a wobbly p95/p99 — normal. The tail reacts to individual heavy pages, cron-like requests, and cold caches.
• p95/p99 climbing while p50 stays flat — a specific part of a site got slow: one heavy page, a slow database query, an external API call timing out. Most visitors are still fine.
• All three lines rising together — the whole server is straining: CPU/memory saturation, PHP workers exhausted, or a database under pressure. Cross-check the Disk/Load/Memory cards at the top of the dashboard.
• A step change after a deploy or plugin update — compare the shape before and after the change; this chart is the fastest regression detector you have.
• A spike in p99 that coincides with a red (5xx) band above — the application was failing and slow; start with the site’s error logs.

Gaps and missing values

• A gap in both charts (no bars, no lines) means the web server was not running during those minutes — after a restart the history up to the stop is preserved, so the gap marks the downtime itself. This is the only thing that breaks the latency lines.
• The latency line spanning a minute with no sample is normal: a minute can carry traffic yet qualify nothing for sampling (only POSTs, only redirects) — or simply be quiet. Nothing was measured there, so the line joins the two neighbouring measurements instead of breaking, and the tooltip shows ”—” for that minute’s percentiles.
• Dots on the lines mark the minutes that were actually measured. They appear whenever the samples are sparse — the usual case on a low-traffic server — precisely so the measurements are distinguishable from the stretches the line merely spans. Read a peak with a dot on it as one slow minute, not as a slow period; without the dots, a single slow minute between two distant measurements would look like a long climb and a long recovery. On a busy server nearly every minute is measured, the dots would only add noise, and the chart drops them.
• A lone dot with no line means a single minute was measured between two downtime gaps — there is no second point to draw a segment to.

Precision

Percentiles are computed from a fixed set of latency buckets, so values are accurate to within a few percent — exactly what you need for reading trends, which is what this panel is for. Treat changes in shape, not the third significant digit, as the signal.