Crash
The crash report tells you a page renderer crashed or became unresponsive, delivered after the page is gone.
Last update:
A crash report tells you a page's renderer process crashed or hung. Because the
page is no longer running, the browser queues the report beforehand and sends it
later from a configured endpoint, which is why crash reporting needs a server
endpoint and cannot be caught in page. The payload is deliberately minimal for
privacy.
Non-standard
Crash reporting is not defined in a current specification and is implemented mainly in Chromium. The body is intentionally sparse.
When the browser sends it
When the renderer crashes (for example out of memory) or becomes unresponsive. The
report is queued before the crash and delivered to the default reporting endpoint (or
a dedicated crash-reporting endpoint) on a later load or session. It cannot be
observed in page through ReportingObserver, because the page is already gone, the
server endpoint is the only way to receive it.
Payload example
{
"type": "crash",
"age": 27,
"url": "https://api-next.centralcsp.com/",
"user_agent": "Mozilla/5.0 ...",
"body": {
"reason": "oom",
"is_top_level": true,
"visibility_state": "visible"
}
}Every crash report body carries these fields inside the shared report envelope.
Field reference
| Field | Meaning |
|---|---|
reason | Why it crashed, for example oom (out of memory) or unresponsive. |
is_top_level | Whether the crashed document was the top-level page. |
visibility_state | Whether the page was visible or hidden at the time. |
stack | An optional JS call stack, included only when reason is unresponsive and Document-Policy: include-js-call-stacks-in-crash-reports is set. |
How to receive it
Declare a default endpoint in Reporting-Endpoints. The report does not arrive
immediately; it is delivered on a subsequent page load or session, so design your
receiver to accept crash reports out of band. CentralCSP collects crash signals
alongside your other reports.
What it tells you about security
Most crashes are stability issues, but a pattern is a signal: repeated out-of-memory or unresponsive crashes concentrated on one page or tied to one script can indicate a denial-of-service condition or a misbehaving (or hostile) third-party script.
Gotchas
Body field names are snake_case. Privacy constraints keep the body minimal, and the JS call stack is only ever included under the specific Document-Policy above.
Browser support
Chromium-based browsers only; not Baseline. Other engines do not emit crash reports.
See also
- Document-Policy
- How the Reporting API works
- Browser crash and unresponsive reports
- Crash monitoring in CentralCSP
- Reporting-Endpoints header
- The report delivery format