The Reporting Layer of app.onepassapps.com: 56 Pages, One Reporting Group, and a Fresh Token on Every Response

I work on OnePassApps, and this is our own site's edge configuration, measured on 10 November 2026 from outside the browser.

I asked for every URL in our sitemap.xml, one at a time, over plain HTTPS, with no cookies and no JavaScript. All 56 of them answered 200. Every one of them carried the same pair of headers describing where an error report would be sent, and nobody had ever published what those two headers actually say.

The pair, on every page

The two headers are report-to and nel. Both are present on 56 of 56 pages, and on every page they carry the same values:

• report-to names one reporting group, cf-nel, with a max_age of 604800 seconds, which is seven days.
• nel is the newer spelling of the same policy: the same group name, the same max_age of 604800, and a success_fraction of 0.0.
• The endpoint in both is a single host, a.nel.cloudflare.com, on the path /report/v4.

Two things are worth noticing before anything else. The first is that success_fraction is 0.0, so the policy is configured to report failures and not successes. The second is the s= parameter on the endpoint URL: it is a long signed string, and it is not the same on any two responses. Across 56 page fetches I counted 56 distinct tokens.

What the edge sends in total

Every page answers with 24 header names. report-to and nel are the only two of them that describe a reporting destination, and they sit next to the rest of the edge's usual set: server reads cloudflare, cf-cache-status reads DYNAMIC, and every response carries a cf-ray value ending in EWR, so all 56 pages in this measurement were answered by the same edge location.

The API host carries the same policy

The API host is a different service, and it answers with 33 header names instead of 24. It carries a report-to header and an nel header too, both pointing at the same reporting group cf-nel and the same endpoint host. So the reporting policy is not something one service has and the other lacks. It is edge-wide.

What I did not see

I did not trigger an error. Every request in this measurement was a plain 200, so no report was ever generated, and I am not claiming to know what a report body looks like or how long it survives. I also did not test any other page on that host beyond the 56 in the sitemap, and I did not vary the request in any way other than the URL.

That is the whole layer: two headers, one group, seven days, a success fraction of 0.0, a signed token that changes on every response, and a reporting host that both of our services point at.

If you want to see the apps themselves, they are at the OnePassApps home page, and every one of them is written up at the app guides.

I work on OnePassApps, so corrections are welcome - especially if you can show me a response from our host that carries a different report-to value.