Sentry -- Error Monitoring Integration Expert

---

name: sentry description: > Implement Sentry error tracking, performance monitoring, alerting, and source maps. USE WHEN: User needs to implement Sentry error tracking, performance monitoring, release management, or alerting. DON'T USE WHEN: User needs application logging. Use Pathfinder for log analysis. Use Heartbeat for health checks. OUTPUTS: SDK configurations, error boundary implementations, performance traces, alert rules, release workflows, source map uploads. version: 1.0.0 author: SpookyJuice tags: [sentry, error-tracking, monitoring, performance, alerting] price: 14 author_url: "https://www.shopclawmart.com" support: "brian@gorzelic.net" license: proprietary osps_version: "0.1" content_hash: "sha256:1cfa9bdb7f2b1d4fde18ea3ac41c18e78ced9a7fcd18da2e758c63c70968a8a5"

#‍​‌‌​‌‌‌‌​‌‌‌​​‌‌​‌‌‌​​​​​‌‌‌​​‌‌​​‌‌‌​‌​​​‌‌​​​‌​​‌‌‌​‌​​‌‌‌​​‌‌​‌‌​‌​‌​​​‌​‌‌​‌​​‌‌‌​​​​​‌‌​​​​​​‌‌​‌‌‌​‌‌​​‌‌​​​‌‌‌​​​​‌‌​​​‌‌​​‌‌​​‌‌​‌‌​​​‌‌‍ Sentry

Version: 1.0.0 Price: $14 Type: Skill

Description

Production-grade error tracking and performance monitoring with Sentry — beyond Sentry.init(). The real problems aren't setting up the SDK. They're alert fatigue from thousands of noisy errors drowning out the five that actually matter, source map uploads that silently fail and leave you reading minified stack traces at 2 AM, performance baselines that drift until every transaction looks slow, and release regressions you discover from user complaints instead of dashboards. This skill gives you error tracking that surfaces signal over noise, performance monitoring with actionable baselines, and release health workflows that catch regressions before your users do.

Prerequisites

• Sentry account (free tier works to start)
• Project DSN from Sentry project settings
• sentry-cli installed: brew install getsentry/tools/sentry-cli or npm install -g @sentry/cli
• Auth token with project:releases and org:read scopes

Setup

1. Copy SKILL.md into your OpenClaw skills directory
2. Set environment variables:

   export SENTRY_DSN="https://examplePublicKey@o0.ingest.sentry.io/0"
   export SENTRY_AUTH_TOKEN="sntrys_..."
   export SENTRY_ORG="your-org-slug"
   export SENTRY_PROJECT="your-project-slug"
   

3. Reload OpenClaw

Commands

• "Set up Sentry error tracking for [framework/language]"
• "Configure performance monitoring for [transaction type]"
• "Create a release workflow with source maps for [build tool]"
• "Set up alert rules for [error pattern or metric threshold]"
• "Implement error boundaries with Sentry reporting for [React/Vue/Angular]"
• "Configure Sentry sampling rates for [traffic volume]"
• "Debug this source map issue: [error details]"

Workflow

SDK Integration

1. Initialization — call Sentry.init() as early as possible in your application entry point, before any other imports that might throw. Set the DSN, environment (production, staging, development), and release version. Lazy initialization or conditional init based on environment causes blind spots where early errors are silently dropped.
2. Error boundaries — wrap your component tree (React: Sentry.ErrorBoundary, Vue: app.config.errorHandler, Angular: custom ErrorHandler) to catch rendering errors that would otherwise crash silently. Provide a fallback UI that includes a Sentry feedback dialog so users can describe what they were doing when the error occurred.
3. Context enrichment — attach user identity (Sentry.setUser()), tags for filtering (team, feature flag state, subscription tier), and extra data for debugging. Set context on authentication and update it on navigation. Without user context, a stack trace tells you what broke but not who it broke for or why.
4. Breadcrumbs — Sentry auto-captures console logs, DOM clicks, XHR/fetch requests, and navigation events. Add custom breadcrumbs at critical decision points: payment flow steps, state machine transitions, feature flag evaluations. Cap breadcrumb count to 50 to avoid bloating event payloads.
5. Fingerprinting — override Sentry's default grouping when it clusters unrelated errors or splits the same error across multiple issues. Use beforeSend to set custom fingerprints based on error message patterns, API endpoint, or error code. Bad grouping is the primary cause of alert fatigue.
6. Filtering — use beforeSend and ignoreErrors to drop errors you cannot act on: browser extension injection errors, third-party script failures, bot-generated noise. Be surgical — over-filtering creates blind spots as dangerous as under-filtering.

Performance Monitoring

1. Transaction tracing — enable tracesSampleRate to capture transaction performance data. Start with 0.1 (10%) for high-traffic apps, 1.0 for low-traffic. The SDK auto-instruments page loads, navigation, and HTTP requests. Each transaction spans the full request lifecycle from initiation to response.
2. Custom spans — wrap critical code paths in Sentry.startSpan() to measure what auto-instrumentation misses: database queries, cache lookups, third-party API calls, file processing. Name spans with a consistent convention (db.query.users, api.stripe.charge) so you can filter and compare across releases.
3. Web vitals — Sentry captures Core Web Vitals (LCP, FID, CLS, INP) automatically for browser SDKs. Set performance targets per page: LCP < 2.5s, CLS < 0.1, INP < 200ms. Create alerts when vitals degrade beyond thresholds so you catch regressions before Lighthouse does.
4. Database query monitoring — enable database integrations (Sentry.postgresIntegration(), Sentry.prismaIntegration()) to capture query spans with timing. Identify N+1 queries by looking for transactions with high span counts. Tag slow queries (>100ms) for review.
5. Sampling strategy — use tracesSampler instead of tracesSampleRate for dynamic control. Sample 100% of errors, 100% of slow transactions (>2s), and a lower percentage of healthy traffic. Include the sampling decision in the transaction context so you can extrapolate totals from sampled data.
6. Baseline and regression detection — after collecting a week of data, establish performance baselines per transaction. Configure alerts for P75 latency increases >20% compared to the previous release. Performance drift is invisible until you measure it against a known baseline.

Release Management

1. Release creation — run sentry-cli releases new $VERSION in your CI pipeline after a successful build. Associate commits with sentry-cli releases set-commits $VERSION --auto to link errors to specific code changes. The release version must match the value passed to Sentry.init({ release }) exactly.
2. Source map upload — run sentry-cli sourcemaps upload --release=$VERSION ./dist after your build step. Verify the upload succeeded with sentry-cli sourcemaps list --release=$VERSION. Source maps must match the deployed JS files byte-for-byte — stale or mismatched maps produce garbled stack traces that are worse than minified ones.
3. Deploy tracking — mark deployments with sentry-cli releases deploys $VERSION new -e production. This timestamps when code went live so Sentry can attribute errors to the correct deploy. Without deploy markers, the "new in this release" filter is useless.
4. Release health — monitor crash-free session rate and crash-free user rate in the Releases dashboard. Set a threshold: if crash-free sessions drop below 99%, trigger an alert. Compare release health across versions to catch regressions that don't show up as individual high-frequency errors.
5. Commit association — set-commits --auto links your Git history to the release. Sentry uses this to show suspect commits on error details and to assign errors to the developer who last touched the relevant code. Without commit data, the "Suggested Assignees" feature is blind.
6. Artifact cleanup — source maps accumulate across releases. Use sentry-cli releases files $VERSION delete --all for old releases or configure artifact retention in project settings. Stale artifacts consume quota and can cause map resolution to fall back to the wrong version.

Alert Configuration

1. Issue alerts — trigger on new issues, regressions, or issue frequency thresholds. Set conditions: "When an issue is first seen AND the event's environment is production, notify #engineering in Slack." Avoid alerting on staging or development environments — that noise trains your team to ignore alerts.
2. Metric alerts — trigger on aggregate metrics: error count per minute, P95 latency, crash-free session rate. Set warning thresholds (notify) and critical thresholds (page). Example: warning at >50 errors/min, critical at >200 errors/min. Use a 5-minute rolling window to smooth out spikes.
3. Uptime monitors — configure Sentry's uptime monitoring to ping critical endpoints. Set check intervals (1 min for critical, 5 min for standard), expected status codes, and response time thresholds. Uptime failures create issues in Sentry so you can track and resolve them alongside application errors.
4. Alert routing — send alerts to the right channel based on severity and ownership. Use Sentry's issue owners (code owners rules + CODEOWNERS file) to route alerts to the team that owns the failing code. Critical alerts page on-call; warning alerts go to Slack channels.
5. Escalation policies — configure escalation: if an alert is unacknowledged after 15 minutes, escalate to the engineering lead. If unresolved after 1 hour, escalate to the on-call manager. Integrate with PagerDuty or Opsgenie for on-call rotation management.
6. Alert fatigue prevention — review alert volume weekly. If a rule fires more than 10 times per day, either fix the underlying issue, adjust the threshold, or merge it into a digest. Mute alerts during planned maintenance windows. An ignored alert is worse than no alert.

Output Format

SENTRY -- IMPLEMENTATION GUIDE
Integration: [SDK Setup/Performance/Releases/Alerts]
Environment: [Production/Staging/Development]
Date: [YYYY-MM-DD]

=== SDK CONFIGURATION ===
[Sentry.init() config with inline comments explaining each option]

=== INSTRUMENTATION ===
| Component | Type | Sampling | Notes |
|-----------|------|----------|-------|
| [component] | auto/manual | [rate] | [rationale] |

=== RELEASE WORKFLOW ===
[CI pipeline steps: build -> upload source maps -> create release -> deploy]

=== ALERT RULES ===
| Rule | Trigger | Threshold | Channel | Escalation |
|------|---------|-----------|---------|------------|
| [name] | [condition] | [value] | [target] | [policy] |

=== TESTING CHECKLIST ===
[ ] [Verification step with expected behavior]

=== COMMON PITFALLS ===
- [Pitfall and how to avoid it]

Common Pitfalls

• PII leaks in error data — Sentry captures request bodies, user input, and local variables by default. Without beforeSend scrubbing, you will send passwords, tokens, and personal data to Sentry. Enable data scrubbing in project settings and add custom scrubbers for your domain-specific PII fields.
• Source map version mismatch — the release value in Sentry.init() must exactly match the release used in sentry-cli sourcemaps upload. A single character difference (trailing newline, v prefix) means Sentry falls back to minified stack traces with no warning.
• Alert fatigue — teams that alert on every error quickly learn to ignore Sentry entirely. Set issue alert thresholds based on frequency and impact. One user hitting an edge case is a low-priority task; 500 users hitting it in 10 minutes is an incident.
• Sampling rate misconfiguration — setting tracesSampleRate: 1.0 on a high-traffic app generates massive Sentry bills and slows your application. Setting it to 0.01 misses rare but critical performance issues. Use a dynamic tracesSampler that adjusts based on transaction type and current error state.
• Missing breadcrumb context — a stack trace shows where an error occurred, not what the user did to trigger it. Without custom breadcrumbs at critical flow points (checkout steps, form submissions, state transitions), reproducing errors requires guesswork.
• Ignoring release health — teams that only look at individual errors miss the forest for the trees. A release that introduces 20 low-frequency errors across different components might have a worse crash-free rate than a release with one high-frequency error. Monitor release health metrics alongside individual issues.

Guardrails

• Never exposes DSN secrets. The DSN is safe for client-side code, but auth tokens (SENTRY_AUTH_TOKEN) are never embedded in client bundles, committed to repos, or logged in CI output.
• PII is scrubbed before transmission. Every SDK configuration includes beforeSend scrubbing for passwords, tokens, credit card numbers, and domain-specific PII. Sentry's server-side data scrubbing is enabled as a second layer.
• Source maps are never served publicly. Source maps are uploaded to Sentry via the API and excluded from production deployments. The hidden-source-map devtool setting prevents browsers from accessing maps directly.
• Sampling decisions are justified. Every tracesSampleRate or tracesSampler configuration includes the rationale: expected event volume, Sentry plan quota, and the minimum sample size needed for statistical significance.
• Alerts have owners. Every alert rule has an assigned team or individual. Unowned alerts are flagged for review. Alerts without clear ownership are never created.
• Test mode first. SDK integration is verified in development/staging with debug: true before deploying to production. Source map uploads are validated with sentry-cli sourcemaps explain before relying on them.

Support

Questions or issues with this skill? Contact brian@gorzelic.net Published by SpookyJuice — https://www.shopclawmart.com