Sentry

Crash and error reporting with stack traces, breadcrumbs and release tracking.

adds it to an existing project · no account needed
Currentas published in v1.5.1
This rule adapts to the rest of your stack. The text below is shown for a project that selected the companion module; a different selection changes a sentence or two.

The rule

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

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.

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/sentry.mdchand-written
---
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.

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 Sentry contributes all of this too — merged with every other module you pick, with conflicts resolved rather than duplicated.

Environment
{{envPrefix}}SENTRY_DSNrequiredProject DSN from Settings → Client Keys. Write-only, safe in the client.
{{envPrefix}}APP_ENVoptionalWhich environment events are tagged with. Read at init, so it has to reach the client bundle.
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
Depends on the rest of the stack — this module installs different packages depending on what else you select, so there is no single list to show.
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 →
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.