App crash and exception events
An app_exception event records that an app hit an error or crash, with a parameter indicating whether it was fatal. In the Firebase/GA4 model it is automatically collected when crash reporting is integrated, linking stability data to behaviour. It is the app analogue of the web exception event: a way to see crashes in the same analytics where you see engagement, so you can connect instability to drop-off.
What it records
When crash reporting is wired into a Firebase/GA4 app, the app_exception event is logged with a parameter marking the error fatal or non-fatal (Firebase automatically collected events). This brings stability into the same analytics as engagement, so you can segment behaviour by whether users hit crashes. The detailed stack data lives in the crash-reporting tool; analytics holds the coarse signal.
Fatal vs non-fatal
A fatal exception is a crash that ends the session; a non-fatal one is a handled error the app survived. Tracking both matters: fatal events show where users are forced out, while non-fatal events are early warnings of fragile code paths. Correlate fatal app_exception spikes with release versions and screens to localise regressions, and keep all context free of personal data.
- Parameter marks fatal vs non-fatal
- Automatically collected when crash reporting is integrated
- Detailed traces live in crash reporting, not analytics
How it appears in analytics and logs
A spike in fatal app_exception events on a screen or release means a crash regression there; non-fatal exceptions flag handled errors worth investigating before they worsen.
Diagnostic use case
See app crashes alongside engagement by analysing app_exception (fatal and non-fatal) so you can connect instability to abandonment and prioritise stability fixes.
What WebmasterID can help detect
WebmasterID records web exception signals first-party; app_exception is the mobile counterpart, included so error tracking is covered across surfaces.
Common mistakes
- Logging stack traces with personal data into analytics.
- Ignoring non-fatal exceptions as early warnings.
- Not segmenting exceptions by app release version.
Privacy and accuracy notes
Exception events should carry a fatal flag and coarse context, not stack traces with personal data or device identifiers. Keep crash context non-identifying in analytics.
Related pages
- The exception event (error tracking)
An exception event records that a client-side error occurred — a JavaScript error or a failed operation. GA4 supports an exception event for this. Tracking errors in analytics ties reliability to behaviour: you can see which pages throw and whether errors correlate with drop-off. The catch is that error messages and stack traces can leak personal data, so what you capture needs care.
- Error click detection
An error click is a UX-signal event where a user's click is shortly followed by a JavaScript error, suggesting the click triggered a fault. Experience tooling correlates click timing with the next thrown error within a window. It is a derived signal, not a native GA4 event; emit it as a custom event. Unlike a dead click (no reaction) it indicates the handler ran and failed.
- The app_update event
app_update is an automatically collected GA4/Firebase event that fires when a user opens an app after it has been updated to a new version. It records the previous app version so you can see adoption of releases and behaviour changes after an update. It is distinct from first_open (a brand-new install) and app_open (any foreground), marking specifically the first launch on a new version.
- Website observability
See errors alongside behaviour, web or app.
Sources and verification notes
- Google Analytics Help — Automatically collected eventsapp_exception with a fatal parameter for crash-reporting apps.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.