Crux Read real Cache-Control headers, edge logs, and SWR client config, then predict the freshness behaviour and the highest-leverage fix.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbit
◷ 14 min
SWR is configured in a header and a few lines of client config, and diagnosed in an edge log. Read each one, trace what the cache actually does, and pick the fix a senior would make first.
Goal
Practise the loop you run on every freshness incident: read the directive or the config, predict the timeline of a request, and reach for the change that fixes the behaviour rather than the symptom.
Reading the header against the timeline, which line is correct?
Heads-up Past max-age but inside stale-while-revalidate, the response is served stale immediately and refreshed out of band — no blocking.
Heads-up stale-if-error=86400 is exactly for this: once the origin errors, the last good copy is served for up to 24h instead of propagating the 503.
Heads-up Inside max-age the entry is fresh and served directly — no origin call at all. Conditional revalidation only happens after expiry, and even then SWR does it in the background.
The log shows origin_inflight climbing into the hundreds for a single key. What is happening, and the fix?
Heads-up The origin is not leaking — the edge is the source, firing a refresh on every stale-hit. A restart just resets the count until the next hot-key expiry repeats it.
Heads-up The SWR window is not the issue — concurrent un-coalesced refreshes are. Shortening it would bring back the synchronous-revalidation spike without stopping the herd.
Heads-up stale-if-error helps when the origin errors, but it does not stop the edge from spawning hundreds of refreshes that CAUSE the errors. The root fix is coalescing.
A user leaves this tab open for an hour, then clicks back into it. What does the SWR client do, and what would two concurrent mounts of this hook in the same tick do?
Heads-up revalidateOnFocus is stale-first: it shows cached data immediately and refreshes in the background. The whole model is no blocking on the refresh.
Heads-up SWR's cache is keyed globally by the request key; concurrent calls for the same key inside dedupingInterval are coalesced onto one in-flight request.
Heads-up revalidateOnFocus: true triggers a revalidation on window focus regardless. That is precisely the trigger described.
Snippet 4 — caching an auth check
GET /api/permissions/user-42Cache-Control: max-age=60, stale-while-revalidate=600
Quiz
Completed
This header is applied to a per-user permissions endpoint. What is the defect?
Heads-up Lengthening the window makes the security hole WORSE — stale 'allowed' is served even longer. The defect is caching an auth decision with SWR at all.
Heads-up 'Eventually' is the problem: between revocation and the next landed refresh, a revoked user is authorized. For access control, eventual is a vulnerability.
Heads-up stale-if-error makes outages serve stale-allowed even longer. No stale-* directive is safe on an authorization decision.
Recap
Every freshness incident is read in a header, a log, or a config. A layered header is three nested windows — fresh, stale-while-revalidate, stale-if-error — and you trace a request by which window its timestamp lands in. An edge log with climbing origin_inflight on one key is the background-refresh herd, fixed by single-flight plus jitter, not a restart. Client config reproduces the model: focus/reconnect revalidation is stale-first, and dedupingInterval coalesces concurrent calls. And no header, anywhere, makes SWR safe on an authorization decision.