# Crashes (/en/docs/platform/monitoring/crash)





The renderer, the browser process that draws your page, stopped running. This is not an exception and not a failed request.

Your own error tracking cannot see these, because JavaScript that reports errors cannot report the moment it stops executing.

Crashes are broken down by reason, separating `oom` from unresponsive:

<img alt="The crash breakdown by reason, separating oom from unresponsive" src="__img0" width="1359" height="359" />

## Columns [#columns]

The report table has these columns:

| Column              | What it means                                             |
| ------------------- | --------------------------------------------------------- |
| **Reason**          | Why the renderer died, using the browser's classification |
| **Document origin** | The page that was open                                    |
| **Browsers**        | Browsers that reported it                                 |
| **Reports**         | Reports collapsed into this row                           |
| **Last seen**       | Most recent occurrence                                    |

Drilling in adds **Visibility**, plus a **stack trace** where the browser supplies one.

## Check visibility before prioritizing [#check-visibility-before-prioritizing]

This is the detail most people miss, and it changes the response entirely.

**Backgrounded** usually means the browser reclaimed memory under pressure. That is closer to normal operating behaviour than to a bug in your code.

**Foreground** means a user watched your site disappear. Treat those first, regardless of volume.

## The `oom` reason [#the-oom-reason]

`oom` means the renderer ran out of memory. On a content site that normally points at a leak, an unbounded list, or images decoded at far higher resolution than they are displayed.

It correlates with long sessions and low-memory devices, which is exactly why it stays invisible in testing on a developer laptop.

## Report count accuracy [#report-count-accuracy]

The browser can only send a crash report after recovering, sometimes on a later visit, and a user who does not return never sends one. Treat totals as a minimum.

That makes trend the useful signal. A steady low level across many pages is normal and needs no action. A jump concentrated on one page after a release is a regression, and the release is where to look.

## Next steps [#next-steps]

* [Network errors](/en/docs/platform/monitoring/nel)
* [Interventions](/en/docs/platform/monitoring/intervention)
* [Crash report reference](/en/docs/web-security/reporting-api/reports/crash)