Most teams do not struggle because the SDK cannot send events. They struggle because the events are missing the metadata needed to answer basic questions quickly: which deploy introduced this, which environment is affected, and how many users are involved?
Environment Naming
- Use a short stable set such as
production,staging, anddevelopment(recommended). - Do not use ephemeral branch names as environments unless that is truly how you triage incidents.
- Keep the same environment names across browser, API, worker, and background services.
Release Naming
- Include the app or service name plus a deploy version, build number, or git SHA.
- Use the same release value across components that ship together when cross-runtime comparison matters.
- Update the release on every deploy so regressions are easy to spot.
web@2026.03.31+git.abc123api@1.18.0worker@2026.03.31.2
User Context and Tags
- Set user identity after authentication and clear it when the session changes.
- Prefer tags such as
service,feature, andregion. - Keep tags low-cardinality so they remain useful for filtering and dashboards.
When to Override Fingerprints
- Only override grouping when you have a clear repeatable rule for how issues should split or merge.
- Do not generate a random fingerprint per event.
- Prefer consistent top-level messages and stack traces before reaching for custom fingerprints.
What Good Metadata Unlocks
- Reliable environment and release filters in issues and events.
- Cleaner issue grouping and more useful regressions.
- Breakdowns by release, browser, environment, and user impact.