Sentry Rust SDK

The Sentry Rust SDK is the officially maintained client for sending errors, panics, tracing spans, and release-health data from Rust applications to Sentry.io (or a self-hosted Sentry instance). The repository is a Cargo workspace of crates: sentry is the batteries-included entry point most applications depend on, sentry-core holds the instrumentation and event-processing primitives that integrations build on, and a family of sentry-* crates (sentry-actix, sentry-anyhow, sentry-backtrace, sentry-contexts, sentry-debug-images, sentry-log, sentry-opentelemetry, sentry-panic, sentry-slog, sentry-tower, sentry-tracing, sentry-types) each wire Sentry into a specific framework or crate ecosystem.

Installing the sentry crate with the appropriate feature flags automatically captures unhandled panics, backtraces, OS/device/Rust runtime context, and (with the relevant integration crate) request context from actix-web, structured spans from tracing, or error chains from anyhow, sending them to Sentry’s ingestion API over HTTPS via the built-in transport feature.

What You Get

• Automatic panic and backtrace capture via the panic and backtrace cargo features, with OS/device/Rust runtime context attached automatically
• A built-in HTTPS transport for sending events to Sentry.io or a self-hosted Sentry instance, with release-health (session tracking) support
• Framework integrations shipped as separate crates: sentry-actix for actix-web request context, sentry-tower for tower/axum middleware, sentry-tracing and sentry-log for structured logging pipelines, sentry-anyhow for error-chain capture
• sentry-opentelemetry for bridging OpenTelemetry spans into Sentry’s performance monitoring
• A sentry-core crate exposing the raw instrumentation primitives for authors writing their own custom integrations

Common Use Cases

• Adding crash and panic reporting to a production Rust web service or CLI tool with a few lines of setup
• Capturing structured application errors and stack traces from an actix-web or tower/axum backend into Sentry’s dashboard
• Bridging existing tracing or log instrumentation into Sentry breadcrumbs and error events without rewriting logging code
• Correlating distributed traces captured via OpenTelemetry with Sentry’s performance monitoring and error grouping

Under The Hood

Architecture - The workspace splits concerns cleanly: sentry-core defines the Hub, Client, Scope, and event/envelope types that everything else builds on; sentry re-exports sentry-core alongside optional feature-gated integrations (backtrace capture, panic hook installation, context collection, debug-image enumeration, and the HTTP transport); and each sentry-<framework> crate (actix, tower, tracing, log, anyhow, slog, opentelemetry) implements that framework’s specific hook points (middleware, layer, subscriber, or error-conversion trait) against the sentry-core API. sentry-types holds the wire-format types shared across the workspace. Tech Stack - Pure Rust workspace using Cargo feature flags extensively to keep the default sentry dependency footprint small (default features: backtrace, contexts, debug-images, panic, transport, release-health); CI runs via GitHub Actions with clippy and rustfmt enforced (clippy.toml, rustfmt.toml at the workspace root), and codecov tracks coverage per PR. Code Quality - Each crate carries its own tests/ and examples/ directories (the sentry crate alone has ~3,875 lines across src/tests/examples); the workspace is Hacktoberfest-tagged and internally labeled team-web-backend, indicating an actively triaged, team-owned project rather than a community-abandoned SDK. Feature-gated compilation is used deliberately to let consumers opt out of transport/backtrace/panic-hook behavior they don’t want, rather than bundling everything unconditionally. API Design - A minimal integration is a single sentry::init() call with a DSN string; framework integrations follow each host framework’s own idioms (a tracing_subscriber::Layer, an actix-web middleware, a tower::Layer) so existing instrumented applications typically add Sentry with a few lines rather than restructuring error handling, which is a deliberate low-friction design goal for an SDK meant to be bolted onto existing codebases.