Shaduf.
HTTP Cache Field Guide/Deployment & incident runbook

Guide · deployment and incidents

Cache deployment and incident runbook

Choose a safe private or public path before deployment, then identify the layer that served old content before you purge anything.

Dated report · 23 Sep 2026 · documentation-only; no live CloudFront, Cloudflare, browser, purge, or origin capture was available.

Start here

  1. Private or sensitive: use no-store when HTTP-cache retention is unacceptable, or private, no-cache when browser retention with validation is acceptable. Keep the route out of shared caching and review the effective key.
  2. Public or versioned: confirm the representation is equivalent for its intended audience, set separate max-age/s-maxage values, use validators, and publish a new URL when bytes change.
  3. During an incident: ask whether a network request occurred; capture named-hop evidence; compare a fresh client and the affected browser; then record a redacted origin marker and counter.

Choose the path

Private / sensitive

  • List cookies, authorization, tenant, role, query, language, device, geography, and server-state inputs.
  • Audit shared-cache rules, key dimensions, workers, application caches, and service-worker Cache Storage.
  • Use a harmless synthetic marker only with authorization. A purge is containment, not a privacy guarantee.

Public / versioned

  • Confirm identical public bytes and keep changed assets on new fingerprinted URLs.
  • Separate browser max-age from shared s-maxage; add ETag or Last-Modified for mutable content.
  • Use a named-provider purge only for its documented scope, then verify the same URL from a named vantage.

Evidence labels

LabelMeaning
Standards-stableHTTP storage audience, freshness precedence, validators, request variants, and named evidence such as Age or optional Cache-Status.
Vendor-specificCloudFront TTL bounds and invalidation, or Cloudflare OCC, Cache Rules, Browser TTL, keys, status fields, and purge methods.
Live-topology-requiredActual rule/key match, POP or tier, stored object, origin counter, browser state, downstream proxy, or purge follow-up.

What a clean result does not prove

No request may be history/back-forward cache or a service worker. A named cache hit is evidence for that request at that named hop. An origin counter increment proves that the instrumented origin received a request. None of these observations clears browser, service-worker, corporate-proxy, other-edge, or application copies.

Read the complete dated runbook →

Search published pools, pages, reports, and evidence.