Sentry
sentryCrash reporting36 lines
Crash and error reporting with stack traces, breadcrumbs and release tracking.
Current — as published in v1.3.2. Written by hand for Sentry, not generated.
The rule
Initialisation
Sentry.init()runs once, as early in startup as possible. Anything thrown before it is lost.enabled: !__DEV__— development noise buries real production issues.environmentmust distinguish development, staging and production.
Reporting
- Report with context, not bare:
ts
Sentry.captureException(error, { tags: { area: 'payments' } });- Reporting is not handling. After capturing, decide what the user sees — a retry, a message, a fallback. A reported error that leaves a blank screen is still a broken screen.
- Add breadcrumbs for domain events. They are what make an error reproducible.
Privacy
- Never put personal data in an event: no email addresses, names, phone numbers, addresses, or message content.
- Never put a token, key, password or session id in tags, extras or breadcrumbs.
- Identify users by internal id only:
Sentry.setUser({ id: userId }). - Clear the user on sign-out:
Sentry.setUser(null).
Do not
- Do not wrap everything in try/catch just to report — unhandled errors are captured automatically, and over-catching hides where a failure came from.
- Do not swallow an error after reporting it unless the fallback is deliberate.
- Do not log an error to the console *and* to Sentry in shipped code.
As each tool receives it
The same guidance, in the shape each editor reads. Cursor and Claude Code are written separately by hand; the rest are derived from the Cursor rule.
.cursor/rules/sentry.mdc
---
description: Sentry error reporting conventions
globs: ["src/**/*.ts", "src/**/*.tsx"]
alwaysApply: false
---
# Sentry
## Initialisation
- `Sentry.init()` runs once, as early in startup as possible. Anything thrown
before it is lost.
- `enabled: !__DEV__` — development noise buries real production issues.
- `environment` must distinguish development, staging and production.
## Reporting
- Report with context, not bare:
```ts
Sentry.captureException(error, { tags: { area: 'payments' } });
```
- Reporting is not handling. After capturing, decide what the user sees — a
retry, a message, a fallback. A reported error that leaves a blank screen is
still a broken screen.
- Add breadcrumbs for domain events. They are what make an error reproducible.
## Privacy
- Never put personal data in an event: no email addresses, names, phone numbers,
addresses, or message content.
- Never put a token, key, password or session id in tags, extras or breadcrumbs.
- Identify users by internal id only: `Sentry.setUser({ id: userId })`.
- Clear the user on sign-out: `Sentry.setUser(null)`.
## Do not
- Do not wrap everything in try/catch just to report — unhandled errors are
captured automatically, and over-catching hides where a failure came from.
- Do not swallow an error after reporting it unless the fallback is deliberate.
- Do not log an error to the console *and* to Sentry in shipped code.
What else this module writes
Selecting Sentry contributes more than a rule file — all of it merged with every other module you pick, with conflicts resolved rather than duplicated.
Environment
EXPO_PUBLIC_SENTRY_DSNrequiredProject DSN from Settings → Client Keys. Write-only, safe in the client.SENTRY_AUTH_TOKENoptionalUploads source maps during CI builds. Never ship in the app.SENTRY_ORGoptionalOrganisation slug, used by the source map upload.SENTRY_PROJECToptionalProject slug, used by the source map upload.Dependencies
@sentry/react-native^8.21.0
Folders
src/services/monitoring/
Put this in your repo
Adds Sentry to a project this tool generated, without starting over. Files you have hand-edited are left alone.