Analytics

Cachely tracks cache performance, bandwidth usage, and traffic patterns for every tenant. Analytics are available in the admin dashboard at two levels: per-tenant detail and account-wide overview.

Per-tenant analytics

Navigate to a tenant's detail page to see the Performance card. It shows:

Cache hit ratio

The percentage of requests served from edge cache without reaching your CMS origin. Calculated from actual cache status headers (HIT vs MISS/BYPASS/ERROR) reported by the edge worker.

A higher ratio means fewer origin requests and lower CMS bandwidth consumption.

Origin requests avoided

The absolute number of requests that were served from cache. Each avoided request is one fewer call to your CMS origin.

For CMS providers with known bandwidth pricing (Prismic, Contentful, Sanity, Storyblok, Cloudinary, Imgix), this shows the estimated cost your CMS would have charged for the same bandwidth. Providers without known pricing (Shopify, generic origins) do not show this metric.

Savings are calculated as: bandwidth_gb * cms_price_per_gb.

Traffic split

When a tenant uses the API proxy (/~api), traffic is split into asset requests and API requests. The traffic split bar shows this breakdown with the API cache hit rate displayed separately.

Recent top paths

The most frequently requested paths based on a recent sample of request logs. This helps identify which assets or API endpoints drive the most traffic.

Top paths are derived from the 200 most recent request log entries (retained for 30 days), so they represent a recent snapshot rather than a complete history.

Account-wide overview

The Overview page aggregates cache metrics across all your tenants:

Cache hit ratio — combined hit ratio across all tenants, calculated from total cache hits and misses
Saved — total estimated CMS bandwidth savings across all tenants

These appear alongside existing overview stats (tenants, requests, bandwidth).

How data is collected

Cache metrics are recorded per request by the edge worker. When a request is served, the worker reports the Cloudflare cache status (HIT, MISS, BYPASS, or ERROR) back to the usage ingest endpoint. These are aggregated into monthly counters in the D1 database.

Cache counters are tracked for all request types — both asset requests and API proxy requests contribute to the overall cache hit ratio.

API-specific counters (API requests, API cache hits, API upstream calls) are tracked separately for API proxy requests only.

Transition period

Cache tracking was introduced after the initial launch. For tenants that had traffic before cache counters were deployed:

The cache hit ratio is calculated from cache_hits / (cache_hits + cache_misses), not from total requests. This ensures the displayed ratio accurately reflects the measured sample.
A note appears when cache data covers less than half of total requests: "Cache metrics based on recent data. Full coverage builds over time."
Metrics that have no data yet show a dash with "Collecting data" instead of misleading zeros.

As new requests flow through, coverage increases automatically until cache counters fully represent all traffic.

Data scope

Granularity: Monthly. Cache counters reset each billing period.
Retention: Current and previous billing period are available.
Top paths: Based on the 200 most recent request log entries per tenant, retained for 30 days.
Savings estimates: Based on published CMS bandwidth prices. Actual CMS billing may vary based on your plan, included allowances, and pricing tier.