Analytics
Cachely records usage at the proxy and presents it per tenant and across the account. The dashboard distinguishes cache performance from CMS billing: a cached response does not by itself establish how much your CMS charged or how much bandwidth was saved.
Per-tenant analytics
Cache hit ratio
The percentage of recorded requests marked HIT, including responses served from edge cache or R2. The denominator includes all recorded request types and statuses, including MISS, BYPASS, STREAM, ERROR, and DISABLED.
A coordinated cold R2 fill can fetch a file from the CMS and then serve it as an R2 HIT. Therefore, cache hits are not an exact count of origin requests avoided.
Measurement coverage
The tenant card compares the request-type counters with the total request counter. If older analytics writes were lost, it shows how many requests have cache measurements and labels the period incomplete. The displayed hit rate then applies only to that recorded subset. Impossible or unavailable counters are not displayed as a valid hit rate.
Counters before October 2026 are unavailable because earlier aggregation failures made those monthly totals unreliable. Missing historical events are not reconstructed from sampled logs.
Response bandwidth and CMS bandwidth equivalent
Response bandwidth uses declared response body lengths. HEAD and bodyless responses such as 304 contribute zero bytes. Unknown body lengths contribute zero; interrupted downloads may transfer less than the declared length. This is not a wire-level transfer measurement or a measurement of CMS-origin bandwidth.
For providers with a reference bandwidth rate, the CMS bandwidth equivalent compares reported response bytes with that reference rate. It is not verified savings or a prediction of the CMS invoice. Provider allowances, account pricing, cold fills, and requests bypassing Cachely are not measured by this comparison.
To confirm a CMS bandwidth target, compare the CMS provider's usage report for the same dates and timezone.
Traffic split and API health
Traffic is split into asset, API, and website requests. The API cache hit rate is shown separately. Non-cached API requests retains the legacy API field name apiUpstreamCalls, but does not count individual upstream fetch attempts: local errors may make no origin call and a retry may make multiple calls.
API health and top paths are based on sampled request logs. Sample request counts are not full traffic totals.
How data is collected
For each usage event received by the app, monthly, daily, and hourly counters are committed together in one atomic database statement before acknowledgement. All periods use the same UTC event timestamp. No counter waits in an in-process timer buffer.
Request logs are sampled independently, at 20% by default. A selected log entry is awaited before the ingest response. A log-storage failure is reported separately and does not cause already committed counters to be submitted again. Log retention defaults to 30 days and is pruned in bounded batches.
The worker reports rejected or timed-out ingest calls in structured logs. It does not blindly retry additive events, since an acknowledgement can be lost after a successful commit. Events that never reach ingest are not recoverable from these counters alone.
Live events update the log stream. Numeric totals refresh from database snapshots approximately every 60 seconds, avoiding double counting when live events overlap a fetched snapshot.
Account-wide overview
Overview metrics aggregate tenant counters for the selected period. Request and bandwidth totals come from persisted usage rows. Historical gaps remain visible as incomplete data; a higher total request count must not be interpreted as a known cache miss for every missing analytics event.
The numeric ratios and reference cost comparisons should be read alongside their coverage labels, not as proof of CMS savings.