Who Actually Uses JS Call Stacks in Crash Reports?
I worked on call stacks in crash reports from unresponsive web pages, which lets a site opt into receiving the JavaScript call stack that was running when its page hung. It went to dev trial in Chrome 125, ran an origin trial through 127–132, and shipped on by default in Chrome 137, about fourteen months ago.
I wanted to know whether anyone had turned it on. For this feature the question is answerable from outside the browser, because the opt-in is a response header. Anyone can go and look.
The Opt-In
A page opts in with a Document Policy directive and a reporting endpoint for the reports to land on:
Document-Policy: include-js-call-stacks-in-crash-reports
Reporting-Endpoints: default="https://example.com/reports"
When the renderer decides a page is unresponsive, the crash report it generates can carry a stack field alongside the usual reason: "unresponsive". The
explainer
and the Crash Reporting spec cover the mechanics.
Because the opt-in is a header rather than a script call, it is visible to any HTTP client. A JavaScript API can only be counted with a use counter inside the browser. A header can be counted by anyone.
What the Web Almanac Shows
The 2025 Web Almanac security chapter added a section on Document Policy, based on the HTTP Archive crawl. Its breakdown of the most common header values:
| Document-Policy value | Desktop | Mobile |
|---|---|---|
include-js-call-stacks-in-crash-reports |
68.48% | 71.99% |
js-profiling |
12.66% | 15.24% |
js-profiling; include-js-call-stacks-in-crash-reports |
17.41% | 11.94% |
force-load-at-top |
1.25% | 0.65% |
no-font-display-late-swap |
0.06% | 0.05% |
The directive is the most common Document Policy value on the web, appearing in roughly 86% of policies on desktop and 84% on mobile once the combined js-profiling value is counted. That sounds better than it is.
The Almanac found Document Policy on about 24,000 desktop and 29,500 mobile pages, which is 0.10% of all pages crawled. The directive dominates a category that is itself rare.
The Almanac's own conclusion is measured: "We expect to see a rise in adoption of Document Policy headers going forward, although future adoption may not happen quickly."
Finding Names
HTTP Archive publishes aggregates rather than site lists, and the percentages above are page-weighted, so a single origin with many crawled pages can dominate them. I wanted specific names.
The results below come from checking the Document-Policy response header across the Tranco top 5,000 domains on July 24, 2026, plus a
short list of application subdomains and public document URLs that apex-only ranking data misses. Response headers only.
Results
Of the top 5,000 domains, 3,682 answered. 53 sent a Document-Policy header, and 32 of those included include-js-call-stacks-in-crash-reports. Grouped by who runs them:
| Operator | Domains observed sending the directive |
|---|---|
| Meta | facebook.com, instagram.com, whatsapp.com, whatsapp.net, wa.me, threads.com, threads.net, meta.com, fb.com, fb.me, fb.watch, m.me, oculus.com, fbcdn.net |
| youtube.com, youtu.be, gemini.google.com, docs.google.com (document and spreadsheet URLs) | |
| Microsoft | outlook.com, live.com, hotmail.com, outlook.live.com, outlook.office.com, outlook.office365.com, outlook.cloud.microsoft, teams.microsoft.com, teams.cloud.microsoft, skype.com, web.skype.com, to-do.office.com |
| VK | vk.com, vk.ru, vkontakte.ru, vkvideo.ru, userapi.com |
| ByteDance | douyin.com, amemv.com, doubao.com |
| Others | temu.com, clickup.com, usatoday.com, thestreet.com, parade.com |
include-js-call-stacks-in-crash-reports — Tranco top 5,000 plus targeted app subdomains, July 24, 2026.Google sends it on YouTube, Gemini and Workspace, where it arrives on document URLs with a per-document Reporting-Endpoints alongside it.
The other 21 domains sent a Document Policy header without the crash-stack directive, mostly js-profiling from sites running Sentry's browser profiling. Those are not counted above.
Limitations
A header scan is easy to over-read, so the limits are worth stating.
-
This is a lower bound. Apex domains miss application subdomains, and unauthenticated requests miss anything behind a sign-in.
google.comdoes not send it butyoutube.comdoes,microsoft.comdoes not butteams.microsoft.comdoes, anddocs.google.com/does not but an actual Google Doc does. A "no" from an origin that redirects to a login screen means unknown rather than absent, and this feature is aimed at exactly the kind of long-lived application that sits behind a sign-in. The real number is well above 32. - Page-weighted and domain-weighted counts are different measurements. The Almanac's 68% and my 32 of 53 are not the same quantity and should not be compared directly.
-
A header is an opt-in, not a working pipeline. A site also needs
Reporting-Endpointsconfigured, an actual unresponsiveness event, and something on the backend that reads thestackfield. The header shows intent, not use. - Attribution is by domain, and a domain count is not a measure of scale. Several operators here own many aliases that all resolve to the same product. "Meta properties send this header" is a statement about bytes on the wire. What any of these companies do with the reports, I do not know.
- This is a snapshot from one day, July 24, 2026. Headers change.
Conclusion
Because the feature is enabled by a response header rather than a script call, adoption can be measured by reading headers that sites already send.
That is a practical argument for header-based opt-ins. They can be inspected and audited by people outside the browser team.
Disclosure: I worked on this feature, and nothing here reflects the views of my employer.
References
- Web Almanac 2025 — Security: Document Policy section, "Most common document policy header values"
- Explainer: Add JS call stacks to crash reports
- Crash Reporting: WICG specification
- Document Policy: WICG specification
- Chrome Platform Status: dev trial 125, origin trial 127–132, shipped 137
- Tranco: the domain ranking used for the scan