The Edge Layer of app.onepassapps.com: One Header, Three Cache Behaviours, and the Age Clock on Our Five Hashed Assets

I work on OnePassApps, so this is our own site's own edge layer, and every number below was measured on app.onepassapps.com with plain HTTPS requests from one server - no browser session, no cookies, no JavaScript - on 10 November 2026.

Three earlier posts of mine each saw one piece of this. What the Server Sends Back listed the header names our pages send. The Revalidation Layer found that our 56 pages carry no validator at all. 23 of 56 Pages Ship No JavaScript noticed that our five hashed assets come back from the edge as a cache hit. None of the three read the Age header, and it turns out to be the only direct proof of which copies the edge is actually serving.

You can try the apps at app.onepassapps.com, and every tool is listed in the app guides.

What I measured

• The 56 URLs in our sitemap.xml, once each
• The 13 static files those pages point at, fetched twice, six seconds apart
• Every response header on all 69 of those requests

All 56 pages answered 200.

One header, three answers

The cf-cache-status header is the edge telling you what it did with the request. On our site it takes three values, and which one you get is decided by the file, not by the page:

The five root static files are the ones without a content hash in the name: /favicon.svg, /favicon.ico, /apple-touch-icon.png, /shell-fallback.css and /shell-fallback.js. The five hashed ones live under /assets/.

Each row lines up with the cache policy that file publishes. I did not change a single header to test that, so I am describing a pattern I measured, not a cause I proved.

The Age header is a clock, not a timestamp

Here is the part no earlier post of mine measured. The five hashed assets are the only responses in the whole set that carry an Age header, and on a cache hit that header is how long the edge has been holding the copy:

Then I fetched all five again six seconds later and every single number moved by exactly six:

• /assets/rolldown-runtime-QTnfLwEv.js moved from 506959 to 506965
• /assets/index-D4M6hlLQ.css moved from 85495 to 85501
• /assets/app-shell-shared-Dsj7SbLS.js moved from 28345 to 28351
• /assets/index-CLafT-_V.js moved from 28345 to 28351
• /assets/react-vendor-DC9Hm7HB.js moved from 28345 to 28351

Six seconds of wall clock, six seconds of Age, on all five files, no rounding and no drift. So the Age value is a live counter on the copy the edge is serving, not a build time stamped into the file. The oldest copy in that table is /assets/rolldown-runtime-QTnfLwEv.js, at 506959 seconds - 5d 20h 49m - which is how long the edge has been handing that file out without going back to the origin.

Nothing on the page surface is ever served from the edge's cache

Not one of the 56 pages carried an Age header, and not one carried an ETag or a Last-Modified. The pages are the only group with no Age at all, and they are the group that needs one least: with max-age=0, must-revalidate, the browser is asked to re-check on every visit anyway.

The five REVALIDATED files have no Age header either, and that is the difference between them and the five HIT files. A revalidated response was fetched from the origin to be confirmed, so the edge is not telling you how old a stored copy is - it is handing you a fresh one.

The two headers nobody reads

Every page carries report-to and nel. These are Cloudflare's network error reporting headers, and they say more than most of the rest.

nel is the compact one, and it is byte for byte the same on all 56 pages:

{"report_to":"cf-nel","success_fraction":0.0,"max_age":604800} 

A success_fraction of 0.0 means only failures are reported, and max_age is 604800 seconds - seven days - which is how long a report stays valid.

report-to is the long one, and it is not the same on any two responses. It names the group, gives the same seven-day max_age, and points at one signed endpoint URL under a.nel.cloudflare.com. Across my 56 page requests I got 56 different report-to values, each with its own token. It is a per-response token for an error report that only failures trigger.

Twelve of the thirteen static files carried the same pair. The one that did not was not ours at all: the analytics beacon, which Cloudflare serves from its own host and which came back with no cf-cache-status header either.

The honest limits

• 69 requests, one network, one region, one build, 10 November 2026.
• The Age figures are a snapshot, and they move on every request by exactly the time between requests.
• I read the alt-svc header advertising HTTP/3, and there is no HTTP/3 client in this measurement, so it was read rather than used.
• I changed no header and ran no experiment, so I am not claiming the cache-control value alone produces the edge answer.
• I did not push any file to its ceiling, so I cannot say what a cache miss or a 429 looks like.
• The report-to endpoints are signed per response, and I am not claiming any of them can be reused.