Sentry

Triage Workflow

1. Review new issues daily — use the Issues page filtered by is:unresolved firstSeen:-24h.
2. Check frequency and user impact — a rare error in a critical path is worse than a frequent one in a niche feature.
3. Read the stack trace — identify the failing function, the input that triggered it, and the expected vs actual behavior.
4. Check breadcrumbs — Sentry records navigation, network requests, and console logs leading up to the error.
5. Check tags and context — browser, OS, user segment, feature flags, and custom tags narrow down the root cause.
6. Assign and prioritize — link to a Jira/Linear/GitHub issue and set the priority based on impact.

Alert Configuration

• Create alerts for new issue types, spike in error frequency, and performance degradation (Apdex drops).
• Use issue.priority and event.frequency conditions to avoid alert fatigue.
• Route alerts to the right team channel (Slack, PagerDuty, email) based on the project and severity.
• Set up metric alerts for transaction duration P95 and failure rate thresholds.

Performance Monitoring

• Use distributed tracing to identify slow spans across services.
• Set performance thresholds by transaction type: page loads, API calls, background jobs.
• Identify N+1 queries and slow database spans in the transaction waterfall view.
• Use web vitals (LCP, FID, CLS) for frontend performance tracking.

Pitfalls to Avoid

• Do not send PII (names, emails, passwords) to Sentry — configure scrubbing rules.
• Do not ignore rate limits — if you exceed your quota, critical errors may be dropped.
• Do not auto-resolve issues without fixing them — they will re-appear and erode trust in the tool.
• Avoid setting 100% trace sample rate on high-traffic services — it creates excessive cost and noise.