Static implementation guide
Cache Observability
Collect response-level and dashboard evidence that distinguishes gateway requests, origin lifecycles, and cached delivery.
Last updated 2026-08-26
Record the request evidence
Each probe line captures the HTTP status, elapsed time, body size, cache state, deployment or edge identifier, and response age. Origin and proxy diagnostic headers confirm that the expected projects participated. The body is consumed completely so timing and byte totals represent the full transfer rather than headers alone.
Cache states can include more than a simple hit or miss, particularly around deployment and revalidation. Preserve the value returned by the platform instead of forcing unfamiliar states into one category. A few initial misses can also occur when requests reach different points of presence.
Correlate with platform usage
Mark the experiment’s UTC start and end, then filter usage and observability views to each project and that exact interval. Compare edge requests, external origin activity, transfer direction, function invocations, and cache distribution. Allow for reporting delay before interpreting an apparent zero.
The expected result is relative: enabled caching should reduce the origin lifecycle after warming. It does not eliminate gateway edge requests, and same-team transfer accounting should not be modeled as two identical billable payloads without platform evidence. Current dashboard measurements and plan documentation are authoritative for cost interpretation.