CDN Analytics
Connect BunnyCDN to see bandwidth, cache performance, and edge traffic alongside your Pulse analytics.
Pulse connects to your BunnyCDN pull zone to bring bandwidth, cache performance, and edge traffic into the same dashboard as your analytics, so you can see what your CDN absorbed and what still reached your origin.
Connect CDN
Go to Settings → Integrations → BunnyCDN and click Connect. Enter a Bunny API key, then choose the pull zone that serves your site from the list Pulse fetches with it.
Note
The API key is read-only, but it is scoped to your whole Bunny account rather than a single pull zone — Bunny does not offer a narrower key. Pulse only ever reads statistics for the zone you select, and syncs automatically every 3 hours.
CDN dashboard
Once connected, visit /sites/{id}/cdn to see the full report.
Two cards sit side by side: Edge, what Bunny absorbed without reaching your origin, and Origin, what got through to your server. A region breakdown sits under Edge, and a response-status breakdown sits under Origin. A separate always-current strip below both cards shows the last 24 hours.
What each number means
Total bandwidth (CDN)
All bytes served over the loaded range, cache and origin together. It isn't a rail of its own — it's the denominator behind "X% of all bandwidth" under Served from cache, and it appears as a line in the tooltip when you hover a point on the chart.
Served from cache
Bytes the CDN cache served over the loaded range without reaching your origin. The delta badge compares against the immediately preceding window of the same length.
Cache hit rate
Cached requests divided by total requests over the range — counted in requests, not bytes, and taken from Bunny's own hit-rate figure rather than a rate Pulse rounds for display. A window with zero requests has no hit rate and shows an em dash, never 0%. The change badge is shown in percentage points rather than percent, and is suppressed when the previous window had fewer than 10 requests to compare against.
Origin traffic
Bytes the cache did not absorb — total bandwidth minus cached bandwidth, which is what reached your origin. The delta here is inverted: a decrease is shown as an improvement, since less origin traffic means the cache did more of the work.
Origin latency
Average origin response time, averaged only over days that actually pulled from the origin. A day with no origin pull renders an em dash rather than 0ms — Bunny reports 0 for an idle day, and that is not something that was measured.
Errors (4xx/5xx)
4xx and 5xx response counts from Bunny's error chart. 3xx responses are not counted as errors here — they are broken out separately as redirects.
Warning
Bunny's error chart returns zero-filled data unless errors are explicitly requested, and until 14 August 2026 Pulse was not requesting them — so counts written before then were fabricated zeros. A full re-sync then rewrote the most recent 364 days with real error counts; anything older than that re-sync's reach still reads zero and proves nothing. Treat those oldest counts as unmeasured, not as a clean record.
Response status composition
The 2xx/3xx/4xx/5xx share of responses over the loaded range, computed from the same daily rows the rails above draw from, so the band and the rails cannot disagree with each other. 3xx is labelled redirects here too, not folded into errors.
Served from (edge regions)
Bandwidth by CDN edge location over the selected range — where the bytes were served from, not where your visitors are, and not a per-day series. It is fetched live for the range each time rather than stored, because the table that used to hold it summed overlapping trailing-window snapshots into multiply-counted totals and recorded every request count as zero.
Last 24 hours (live card)
A separate, always-current instrument covering the trailing 24 complete UTC hours, deliberately not wired to the date range picker above it. The hour in progress is excluded from the totals and is not plotted, and an hour with no requests draws no bar rather than a minimum-height sliver. If a live refresh fails after a good load, the card keeps its last window on screen and relabels itself as failing rather than presenting stale numbers as current.
CDN days are UTC days
CDN daily rows are Bunny's own UTC calendar days — verified by checking that hourly buckets sum exactly to the daily bucket — not the site's local day the rest of Pulse reports in. Every date on this page, including the range presets and axis labels, is anchored to UTC for that reason, so a day here will not line up with the same-numbered day on your analytics dashboard unless your site's timezone is also UTC.
Zero-fill means absence
Bunny returns a value for every bucket asked about, including hours that have not happened yet and days before your zone carried any traffic, so a stored zero cannot be told apart from "nothing was measured" on its own. Pulse does not persist a bucket that is zero on every metric, and a bucket with no requests renders a dash rather than a fabricated 0% hit rate or 0ms latency.
How far CDN history goes back
Bunny's statistics endpoint enforces two limits: a maximum 40-day width per request, and an undocumented age cap that rejects any start date older than a year. Together they bound backfilled history at 364 days no matter how long your site has been connected — the zone line at the bottom of the page states when the loaded data begins if your requested range runs into that limit.