playbooks

home / skills / jeremylongshore / claude-code-plugins-plus-skills / sentry-reliability-patterns

sentry-reliability-patterns skill

/plugins/saas-packs/sentry-pack/skills/sentry-reliability-patterns

This skill helps you implement resilient Sentry integrations by adding retry, offline queues, circuit breakers, and dual-write redundancy.

npx playbooks add skill jeremylongshore/claude-code-plugins-plus-skills --skill sentry-reliability-patterns

Review the files below or copy the command above to add this skill to your agents.

Files (9)
SKILL.md
1.8 KB
---
name: sentry-reliability-patterns
description: |
  Build reliable Sentry integrations.
  Use when handling SDK failures gracefully,
  implementing retry logic, or ensuring error tracking uptime.
  Trigger with phrases like "sentry reliability", "sentry failover",
  "sentry sdk failure handling", "resilient sentry setup".
allowed-tools: Read, Write, Edit, Grep
version: 1.0.0
license: MIT
author: Jeremy Longshore <[email protected]>
---

# Sentry Reliability Patterns

## Prerequisites

- Understanding of failure modes
- Fallback logging strategy
- Network reliability characteristics
- Graceful shutdown requirements

## Instructions

1. Wrap Sentry.init with try/catch for graceful initialization failure handling
2. Implement fallback capture function that logs locally if Sentry fails
3. Add retry with exponential backoff for network failures
4. Implement offline event queue for intermittent connectivity
5. Add circuit breaker pattern to skip Sentry after repeated failures
6. Configure request timeout with wrapper function
7. Implement graceful shutdown with Sentry.close() on SIGTERM
8. Set up dual-write pattern to multiple error trackers for redundancy
9. Create health check endpoint to verify Sentry connectivity
10. Test all failure scenarios to ensure application continues operating

## Output
- Graceful degradation implemented
- Circuit breaker pattern applied
- Offline queue configured
- Dual-write reliability enabled

## Error Handling

See `{baseDir}/references/errors.md` for comprehensive error handling.

## Examples

See `{baseDir}/references/examples.md` for detailed examples.

## Resources
- [Sentry Configuration](https://docs.sentry.io/platforms/javascript/configuration/)
- [Transport Options](https://docs.sentry.io/platforms/javascript/configuration/transports/)

Overview

This skill teaches practical patterns to build reliable Sentry integrations that tolerate SDK and network failures. It focuses on graceful degradation, retry strategies, offline queuing, and redundancy so error tracking does not become a single point of failure. Use these patterns to preserve application stability and maintain observability under adverse conditions.

How this skill works

The skill inspects common failure modes around Sentry initialization, network transport, and runtime capture calls, then applies defensive patterns: guarded initialization, fallback capture, exponential backoff retries, offline event queuing, and a circuit breaker to avoid repeated failures. It also covers operational features like request timeouts, graceful shutdown hooks to flush events, dual-write redundancy, and health endpoints to validate connectivity.

When to use it

  • When Sentry SDK failures must not impact application availability
  • When network reliability is intermittent and events may be dropped
  • When you need redundant error reporting (dual-write) for uptime SLAs
  • When you want controlled retries and backoff to avoid cascading load
  • When graceful shutdown must flush pending error reports

Best practices

  • Wrap Sentry.init in a try/catch and fall back to local logging if init fails
  • Expose a single capture wrapper that performs local logging, enqueues events, retries, and delegates to Sentry when healthy
  • Use exponential backoff and jitter for retrying transient transport errors; escalate or drop after configurable limits
  • Implement an offline queue persisted to disk for intermittent connectivity and flush on reconnect or shutdown
  • Add a circuit breaker that opens after repeated transport errors to prevent wasted work and allow quick recovery
  • Provide a health-check endpoint that verifies Sentry transport and reports degraded mode

Example use cases

  • A web service that must continue serving requests if Sentry is unreachable, logging errors locally and syncing later
  • A mobile or edge process with intermittent connectivity that queues events on disk and uploads when online
  • A high-volume backend that dual-writes to Sentry and a backup tracker to meet monitoring SLAs
  • A containerized microservice that flushes pending events on SIGTERM during orchestrator-driven shutdowns

FAQ

How do I decide queue size and retry limits?

Base them on expected error rate, available disk, and acceptable duplication. Start small, monitor, and increase limits only if you can handle replay load.

Will dual-write cause duplicate alerts?

Yes, dual-write can duplicate events across systems. Deduplicate downstream or use sampling/metadata tags to indicate origin.