Crashlytics

Firebase crash reporting for native mobile apps, with crash-free user metrics.

adds it to an existing project · no account needed
Currentas published in v1.5.1

The rule

This is the whole text, exactly as your agent receives it. Nothing is held back for the paid tier.

What is automatic and what is not

  • Native crashes are captured automatically.
  • JavaScript errors are not. Report the ones that matter with crashlytics().recordError(error).
  • crashlytics().log() adds breadcrumbs to the next crash. Use it for domain events, not for chatter.

Reporting is not handling

After recording an error, decide what the user sees — a retry, a message, a fallback. A reported error that leaves a blank screen is still a broken screen.

Privacy

  • Identify users by internal id only: setUserId(userId).
  • No email addresses, names, phone numbers or message content in logs, custom keys or the user id. Reports are stored by a third party.
  • No tokens or credentials, ever.

Configuration

  • Disable collection in development, or your own crashes bury the real ones.
  • Symbol files must upload with every release build, or the stack traces are memory addresses.

Never

  • Never assume a crash appears without relaunching the app — the report uploads on next launch.
  • Never rely on Crashlytics alone for a JavaScript-heavy failure path.

6 formats, one per tool

Each tab is the file that tool actually reads, at the path it actually looks in. Knowing where each one looks is most of the work of supporting it.

.cursor/rules/crashlytics.mdchand-written
---
description: Crashlytics conventions
globs: ["src/services/monitoring/**", "src/**/*.ts", "src/**/*.tsx"]
alwaysApply: false
---

# Crashlytics

## What is automatic and what is not

- Native crashes are captured automatically.
- **JavaScript errors are not.** Report the ones that matter with
  `crashlytics().recordError(error)`.
- `crashlytics().log()` adds breadcrumbs to the next crash. Use it for domain
  events, not for chatter.

## Reporting is not handling

After recording an error, decide what the user sees — a retry, a message, a
fallback. A reported error that leaves a blank screen is still a broken screen.

## Privacy

- Identify users by **internal id only**: `setUserId(userId)`.
- No email addresses, names, phone numbers or message content in logs, custom
  keys or the user id. Reports are stored by a third party.
- No tokens or credentials, ever.

## Configuration

- Disable collection in development, or your own crashes bury the real ones.
- Symbol files must upload with every release build, or the stack traces are
  memory addresses.

## Never

- Never assume a crash appears without relaunching the app — the report uploads
  on next launch.
- Never rely on Crashlytics alone for a JavaScript-heavy failure path.

Hand-written by the module author, frontmatter and all. It is the source the four derived formats are rendered from, so a correction lands here first.

What else this module writes

The rule is one file of several. Selecting Crashlytics contributes all of this too — merged with every other module you pick, with conflicts resolved rather than duplicated.

Dependencies
@react-native-firebase/app^26.1.0@react-native-firebase/crashlytics^26.1.0
Folders
src/services/monitoring/

Advisory history

Every time this rule turned out to be wrong, and what we did about it.

No corrections yet

This rule has been accurate since it was published. That is a fact about the rule, not a promise about the future — which is the whole reason this section exists.

Pro tells you the day a correction lands that affects a repo you actually have.

See what Pro adds →

Rules people add alongside this one

Put this rule in a real project

The wizard picks the rest of the stack with you, writes all 6 formats, and leaves a manifest so check can tell you when any of it drifts.