Observed change interval
avg —
min — · max —
Purpose: time between payload timestamp updates to verify background revalidation cadence.
Fastly SWR Edge Cache Dashboard
Use Start to begin the SWR test session.
CDN: Fastly SESSION_ID: cf62fc2b-80c7-4bce-a16c-bf4b86c04b97 Waiting for data state: warming up
No polls yet. Start collecting responses to evaluate SWR behavior.
Browser cache is disabled with Cache-Control: no-store, no-cache, max-age=0, must-revalidate.
CDN cache uses Surrogate-Control: public, max-age=10, stale-while-revalidate=86400.
max-age controls when revalidation starts, while stale-while-revalidate controls how long stale content can still be served.
Polling runs every 2-4s (jittered), using /api/time.json?session=<SESSION_ID>.
The endpoint has an artificial response delay jitter of 2-6s.
Expected behavior: most polls are fast from edge, and payload updates usually land around 12-20s after the previous change.
Next poll
Countdown
paused
Headers (latest poll)
CF-Cache-Status
—
Age
—
Surrogate-Control
—
X-Debug-Cache-Policy
—
Audit log (latest 100 checks)
| # | Session | Duration | Server now (mm:ss.ms) | Recv | Age | Δ payload | CF-Cache-Status | Age hdr |
|---|---|---|---|---|---|---|---|---|
| No log rows in this filter. | ||||||||
How to read this
- state: warming up means cache is still being populated.
- state: running means warm-up signals were seen and steady-state checks apply.
- response timer is the key signal; values above 1.0s are highlighted red.
- MISS is expected during warm-up only; MISS while running should be treated as a cache issue.
Expected policy: no browser cache + public, max-age=10, stale-while-revalidate=86400