# Crashs (/fr/docs/platform/monitoring/crash)





Le moteur de rendu qui affichait votre page a cessé de tourner. Ce n'est pas une exception, ni une requête en échec.

Votre propre suivi des erreurs ne peut pas les voir, parce que le JavaScript qui remonte les erreurs ne peut pas remonter l'instant où il s'arrête.

<img alt="Le détail des plantages par raison, séparant oom de unresponsive" src="__img0" width="1359" height="359" />

## Colonnes [#colonnes]

| Colonne             | Signification                                                               |
| ------------------- | --------------------------------------------------------------------------- |
| Motif               | Pourquoi le moteur de rendu est mort, selon la classification du navigateur |
| Origine du document | La page qui était ouverte                                                   |
| Navigateurs         | Les navigateurs qui l'ont signalé                                           |
| Reports             | Les reports regroupés dans cette ligne                                      |
| Dernière occurrence | L'occurrence la plus récente                                                |

Le détail ajoute **Visibilité**, ainsi qu'une **stack trace** quand le navigateur en fournit une.

## Vérifier la visibilité avant de prioriser [#vérifier-la-visibilité-avant-de-prioriser]

C'est le détail que la plupart des gens ratent, et il change complètement la réponse à apporter.

**En arrière-plan** signifie en général que le navigateur a récupéré de la mémoire sous pression. C'est plus proche d'un fonctionnement normal que d'un bug dans votre code.

**Au premier plan** signifie qu'un utilisateur a vu votre site disparaître. Traitez ces cas en premier, quel que soit le volume.

## Lire `oom` [#lire-oom]

`oom` signifie que le moteur de rendu a manqué de mémoire. Sur un site de contenu, cela pointe normalement vers une fuite, une liste sans limite, ou des images décodées à une résolution bien supérieure à celle où elles sont affichées.

Le phénomène va de pair avec les sessions longues et les appareils peu dotés en mémoire, ce qui explique précisément pourquoi il reste invisible aux tests sur un portable de développeur.

## Les compteurs sont des planchers [#les-compteurs-sont-des-planchers]

Le navigateur ne peut envoyer un report de crash qu'après s'être rétabli, parfois lors d'une visite ultérieure, et un utilisateur qui ne revient pas n'en envoie jamais. Traitez les totaux comme un minimum.

C'est donc la tendance qui porte le signal utile. Un niveau bas et stable réparti sur beaucoup de pages, c'est le bruit de fond du web. Un pic concentré sur une seule page après une mise en production est une régression, et c'est cette mise en production qu'il faut regarder.

## Étapes suivantes [#étapes-suivantes]

* [Erreurs réseau](/fr/docs/platform/monitoring/nel)
* [Interventions](/fr/docs/platform/monitoring/intervention)
* [Référence du report de crash](/fr/docs/web-security/reporting-api/reports/crash)