Skip to content
CAI
Software that uses CAICheck a score

getsentry/sentry-elixir

77.8

Strong · 3 October 2026

17.2k

lines of production code

Elixir

primary language

2

measurements over time

CAI band scale
CAI trend line
CAI lens gauges

What this system is

This system is the official Sentry SDK for Elixir, designed to capture and transmit application telemetry—including exceptions, logs, metrics, and distributed traces—to the Sentry platform. It provides deep integrations with the Elixir ecosystem, automatically instrumenting Phoenix web requests, Oban background jobs, and Quantum cron tasks while supporting OpenTelemetry for cross-service tracing. The SDK features a robust, high-performance transport layer with rate limiting and buffering, alongside utilities for source code context packaging and isolated testing.

How it got here

2014–2024 — SDK architecture and integration expansion

28 changes.

The project evolved from initial scaffolding into a comprehensive Sentry SDK for Elixir, featuring a major architectural rewrite with a new transport layer, structured logging, and cron monitoring. Significant effort was dedicated to expanding integrations with Phoenix, Oban, and Quantum, alongside the creation of a robust end-to-end test suite using a dedicated Phoenix application fixture.

2025–2026 — OpenTelemetry integration and test infrastructure

21 changes.

This period focused on implementing first-class OpenTelemetry distributed tracing support, including custom propagators for Phoenix LiveView and Oban, alongside a priority-based Telemetry Processor for buffered data sending. Significant effort was also dedicated to expanding test coverage, introducing a dedicated testing library for assertion helpers and configuration isolation, and adding comprehensive integration tests for legacy OTel compatibility and end-to-end tracing scenarios.

Features

Add Sentry configuration to umbrella test integration

The test\_integrations/umbrella location now includes a .formatter.exs, .gitignore, README, and config/config.exs. The configuration file sets up Sentry with a local DSN and enables source code context, while explicitly defining in\_app\_otp\_apps as \[:public, :admin\] to control which OTP applications are considered 'in-app' for error reporting.

_test\integrations/umbrella · high confidence

Added Phoenix app scaffolding for integration testing

This change introduces the foundational structure for a Phoenix application located in the \test\_integrations/phoenix\_app\ directory, intended to serve as an end-to-end test environment. The addition includes the core Elixir modules (\PhoenixApp\ and \PhoenixAppWeb\) which set up the web interface, router, and LiveView configurations. On the frontend, it adds a Tailwind CSS configuration with custom variants for Phoenix LiveView states (e.g., \phx-click-loading\) and Heroicon integration, alongside the necessary JavaScript entry point (\app.js\) to initialize the Phoenix Socket and LiveSocket, and a vendor copy of the \topbar\ library for page-load progress indicators.

_test\_integrations/phoenix\_app/assets, test\_integrations/phoenix\app/lib · high confidence

Added Telemetry integration and check-in ID mapping support

The Sentry library now includes a new Telemetry integration that automatically captures failures from Telemetry handlers, reporting them as exceptions or messages with relevant metadata like handler ID and event name. Additionally, a new GenServer-based ETS table (\CheckInIDMappings\) has been introduced to map cron check-in keys to unique UUIDs, with automatic periodic purging of stale entries to manage memory usage.

lib/sentry/integrations · high confidence

Added end-to-end Phoenix application for integration testing

A new Phoenix application has been added to the test suite to serve as a realistic integration target. It includes an Accounts context with Ecto schemas, a Billing context featuring a CreditCard struct designed to test PII scrubbing in stacktraces, and an Oban worker for simulating background job failures. The application is configured with OpenTelemetry instrumentation (Bandit, Phoenix, Oban, Ecto) and Sentry context propagation to validate distributed tracing and structured logging. A custom Sentry HTTP client is also included to log event envelopes to a file for end-to-end test validation.

_test\_integrations/phoenix\_app/lib/phoenix\app · high confidence

Automated version bumping and lockfile refresh scripts

Added two new shell scripts to the project: \bump-version.sh\ automates the process of updating the version string in \mix.exs\ by replacing the existing version with a specified new one, while \refresh\_lockfiles.sh\ updates Elixir dependency lockfiles (supporting multiple OTP version buckets) by attempting bulk updates first and falling back to individual dependency updates if compilation fails, providing a summary of results.

scripts · high confidence

First-class OpenTelemetry distributed tracing support

The SDK now includes a complete OpenTelemetry integration that enables distributed tracing across service boundaries. This introduces a custom propagator to handle \sentry-trace\ and \sentry-baggage\ headers, a sampler that respects Sentry's sampling configuration and trace continuation rules, and a span processor that manages the lifecycle of spans and transactions. For Phoenix LiveView applications, a dedicated propagator ensures that WebSocket lifecycle events are correctly nested under the original HTTP request trace. The implementation also supports Oban job tracing, OTel span links, and stricter handling of trace formats and ignored HTTP status codes.

lib/sentry/opentelemetry · high confidence

Initial Phoenix test application scaffolding

The test integration suite now includes a complete Phoenix application scaffold under \test\_integrations/phoenix\_app/priv\. This adds the necessary infrastructure for end-to-end testing, including an Ecto migration to create a \users\ table, a second migration to integrate the Oban background job library, standard Ecto validation error messages for internationalization, a project logo, and a \robots.txt\ file.

_test\_integrations/phoenix\app/priv · high confidence

Initial project scaffolding and configuration

The repository has been initialized with the core configuration files required for development and release management. This includes \.craft.yml\ to define release targets (Hex, registry, GitHub) and minimum version, \.dialyzer\_ignore.exs\ to suppress known type-checking warnings, \.formatter.exs\ to standardize code formatting with Plug and Phoenix dependencies, and \.gitignore\ to exclude build artifacts, test integrations, and local IDE settings. Documentation and contribution guidelines are also established via \AGENTS.md\, \CONTRIBUTING.md\, and \ISSUE\_TEMPLATE.md\, while \coveralls.json\ configures code coverage reporting to skip test support files.

(repo-wide) · high confidence

Introduces a priority-based Telemetry Processor with buffered sending

The SDK now includes a new Telemetry Processor that manages the sending of telemetry data (errors, transactions, check-ins, logs, and metrics) using a weighted round-robin scheduler. This processor introduces fixed-capacity FIFO buffers for each data category, allowing items to be batched and flushed based on priority levels (critical for errors, high for check-ins, medium for transactions, and low for logs/metrics). This change ensures that critical telemetry is prioritized over high-volume data under load, while also providing configurable buffer capacities, batch sizes, and timeouts to control memory usage and sending behavior.

lib/sentry/telemetry · high confidence

Maintains distributed tracing continuity for Phoenix LiveView

A new \Sentry.Plug.LiveViewContext\ plug has been added to bridge the gap between HTTP request tracing and LiveView process lifecycles. Because LiveView creates fresh BEAM processes for each lifecycle callback (mount, handle\params, etc.), these processes do not automatically inherit the OpenTelemetry context from the initial HTTP request. This plug serializes the current trace context (specifically the \sentry-trace\ and \baggage\ headers) into the session under the key \\\_sentry\_lv\ctx\\_\. This allows the \Sentry.OpenTelemetry.LiveViewPropagator\ to restore the context in subsequent LiveView processes, ensuring that all spans created during the LiveView lifecycle share the same trace ID as the original HTTP request. Users must add this plug to their router pipeline after the session plug and before LiveView routes to enable this behavior.

lib/sentry/plug · high confidence

New Mix tasks for installation, testing, and source packaging

This release introduces three new Mix tasks to streamline Sentry integration and debugging. The \mix sentry.install\ task uses Igniter to automatically configure the DSN, environment name, and source code context in \prod.exs\, add the \Sentry.LoggerHandler\ to the application supervisor, and conditionally add \Sentry.PlugCapture\ for Phoenix apps using Cowboy. The \mix sentry.send\_test\_event\ task allows users to verify their configuration by sending a test exception or message to Sentry, displaying client details and the resulting event ID or exclusion reasons. Additionally, \mix sentry.package\_source\_code\ packages application source code into a \sentry.map\ file, enabling Sentry to provide accurate source context in error reports when used before building a release.

lib/mix · high confidence

New Phoenix integration test application with tracing and scrubbing endpoints

Added a new Phoenix application (\PhoenixAppWeb\) in the test integrations directory to serve as an end-to-end test fixture. This includes core UI components (modals, flash notices), layout templates, and a suite of controller and LiveView endpoints designed to exercise Sentry's distributed tracing, async span handling, and PII scrubbing capabilities. Specific endpoints allow testing trace context propagation across background tasks, verifying parameter scrubbing in error reports, and toggling configuration settings like strict trace continuation at runtime.

_test\_integrations/phoenix\_app/lib/phoenix\_app\web · high confidence

New Phoenix test application with Sentry, OpenTelemetry, and Oban configuration

A new end-to-end test Phoenix application has been added to the test suite, providing a realistic environment for validating the Sentry Elixir SDK. The configuration integrates Sentry with OpenTelemetry for distributed tracing (using Sentry's SpanProcessor and Propagator) and Oban for job processing. It includes environment-specific setups for development, testing, and production, enabling features such as source code context, structured logging, metrics reporting, and strict trace continuation. The app also supports runtime configuration via environment variables and includes specific handling for Elixir 1.18+ and 1.19+ compatibility regarding source code exclusion patterns.

_test\_integrations/phoenix\app/config · high confidence

New test helpers and per-test configuration isolation

The Sentry SDK now includes a dedicated testing library (\Sentry.Test\) to simplify verifying Sentry reports in your test suite. This adds \Sentry.Test.Assertions\, providing assertion helpers like \assert\_sentry\_report/2\, \assert\_sentry\_log/3\, and \assert\_sentry\_metric/2\ that automatically handle asynchronous telemetry processing and polling. Additionally, \Sentry.Test.Config\ enables per-test configuration isolation, allowing you to override settings (such as the DSN) on a per-test basis without affecting other tests, even when running with \async: true\.

lib/sentry/test · high confidence

Sentry SDK for Elixir v14.0.0

This release introduces the Sentry SDK for Elixir, providing a library to submit events (exceptions, messages, transactions, logs, and metrics) to Sentry. It supports manual capture, automatic capture for Plug/Phoenix applications, and integrations via Erlang \:logger\ handlers and Elixir \Logger\ backends. Configuration is read at application start and cached in \:persistent\_term\ for performance, with support for system environment variables like \SENTRY\_DSN\. Key features include event filtering via \:before\_send\ callbacks, custom grouping via fingerprinting, client reports, and crash-safe callback handling where failures are logged and the item is dropped rather than crashing the application.

lib · high confidence

Support for monitoring Quantum cron jobs in Sentry

The Quantum integration now captures check-ins for scheduled jobs, allowing users to monitor cron job execution status and duration in Sentry. The new \Sentry.Integrations.Quantum.Cron\ module attaches to Quantum telemetry events to report jobs as in-progress, successful, or errored. It automatically maps job schedules (such as \@hourly\, \@daily\, or custom cron expressions) to Sentry monitor configurations and includes timezone information. Jobs without a specific name are handled gracefully by generating a generic slug and logging a warning, ensuring that even nameless jobs are tracked.

lib/sentry/integrations/quantum · high confidence

Behavioural changes

Client reports now track discarded spans, logs, and metrics

The client report sender now accurately records discarded items including transactions (and their contained spans), log events, and metrics. This ensures that Sentry receives correct telemetry on dropped data, accounting for byte sizes and specific outcome categories as required by the Sentry protocol.

_lib/sentry/client\report · high confidence

Enhanced Oban integration with custom reporting controls and cron check-ins

The Oban integration now supports finer-grained control over error reporting and adds built-in monitoring for cron jobs. Users can configure custom callbacks via \:should\_report\_error\_callback\ and \:should\_report\_error\_check\_in\_callback\ to decide whether specific job exceptions or cron check-ins should be reported to Sentry. Additionally, the integration now captures check-ins for Oban cron jobs, allowing you to monitor their execution status in Sentry, with support for custom monitor slugs and per-module configuration options via \sentry\_check\_in\_configuration\. Error reporting also improves by scrubbing sensitive job arguments and handling non-list stacktraces gracefully.

lib/sentry/integrations/oban · high confidence

Logger handler refactored into pluggable backends with structured log support

The Sentry Logger Handler has been restructured to support both error capture and structured logs via a new pluggable backend architecture. The original error-handling logic is now isolated in \Sentry.LoggerHandler.ErrorBackend\, which continues to capture crashes and errors to Sentry's error API. A new \Sentry.LoggerHandler.LogsBackend\ has been added to send structured log events to Sentry's Logs Protocol, allowing users to capture detailed log metadata. This change also introduces a new \Sentry.LoggerHandler.Backend\ behavior for defining custom handling strategies, and includes a new \Sentry.LoggerHandler.RateLimiter\ to manage event throughput for both backends.

_lib/sentry/logger\handler · high confidence

Major SDK rewrite with new architecture and structured logging support

The Sentry Elixir SDK has been significantly refactored to improve reliability, performance, and feature parity. The core event pipeline is now managed by a new \Sentry.Client\ module, which handles event creation, callback execution, and sampling. A new \Sentry.TelemetryProcessor\ buffers and transports events, while \Sentry.Dedupe\ uses ETS to prevent duplicate reports. The SDK now supports structured logging via \Sentry.LoggerHandler\, allowing log messages to be sent as events. New capabilities include cron monitoring via \Sentry.CheckIn\ (with integrations for Oban and Quantum), runtime metrics reporting, and client reports for tracking discarded events. The HTTP client has been switched from Hackney to Finch, and configuration is now validated using \NimbleOptions\. Additionally, the SDK introduces support for attachments, transactions, and improved scrubbing of sensitive data in Plug contexts and URLs.

lib/sentry · high confidence

New test configuration and Finch client adoption

The project now includes a dedicated test configuration block that sets up Sentry for testing with synchronous sending, a 50ms Finch receive timeout, and OpenTelemetry span processing. It also configures the logger backend conditionally based on the Elixir version (using :logger\_std\_h for versions \> 1.16.0, otherwise clearing backends) and sets the default HTTP client to Sentry.FinchClient.

config · high confidence

New transport layer with sender pool and rate limiting

The SDK now uses a new transport architecture in lib/sentry/transport that replaces the previous sending mechanism. This introduces a sender pool (Sentry.Transport.SenderPool) that distributes event and transaction sending across multiple GenServer workers to improve concurrency and avoid race conditions. It also adds a dedicated rate limiter (Sentry.Transport.RateLimiter) backed by an ETS table to track per-category and global rate limits from Sentry API responses, ensuring events are dropped locally when limits are hit. This change affects how events and transactions are queued, sent, and rate-limited, providing more robust handling of high-throughput scenarios and compliance with Sentry's rate-limiting specifications.

lib/sentry/transport · high confidence

Test coverage

Add test apps to verify Sentry in\_app\_module\_allow\_list configuration; Added comprehensive test coverage for core Sentry modules; Added end-to-end Phoenix application test fixture; Added end-to-end test suite for distributed tracing and parameter scrubbing; Added integration tests for Phoenix controller features; Added integration tests for User LiveView; Added integration tests for production mode behavior with nil DSN; Added integration tests for tracing, metrics, and Oban behavior; Added test coverage for OpenTelemetry integration components; Added test fixtures for example umbrella apps; Added test helpers and assertion macros for Sentry reports and logs; Added test scope registry for managing Sentry test isolation; Added test support infrastructure and helpers for the Phoenix integration; Added tests for LiveView trace context filtering; Added tests for Oban cron and error reporting integrations; Added tests for Quantum cron job check-in reporting; Added tests for Sentry Mix tasks; Added tests for Telemetry Buffer, Scheduler, and Category modules; Added tests for client report sender logic; Added tests for legacy OpenTelemetry version compatibility; Added tests for runtime metrics reporting; Added tests for the Sentry Logger Handler; Added tests for the Sentry transport rate limiter; Added tests for the Telemetry integration; Expanded test coverage for core SDK components; Legacy OpenTelemetry integration test suite added; New test support infrastructure for isolated and stable testing.

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

How this codebase got here

Score

  • CAI 77 → 78 (+0.7)
  • Rubric changed (rubric-2026.09.15 → rubric-2026.10.1) — scores are not directly comparable.

Lenses

  • Code Health 92 → 92 (+0.0)
  • Architecture 93 → 93 (+0.1)
  • Maturity 68 → 68 (-0.0)
  • Readiness 82 → 82 (-0.7)
  • Security 84 → 86 (+2.4)
  • Performance 100 (new)

Resolved (10)

  • Duplicated block (18 lines × 2) (lib/sentry/integrations/oban/cron.ex)
  • Duplicated block (6 lines × 2) (lib/sentry/telemetry/buffer.ex)
  • Off-boarding risk: anonymized user #1
  • Outdated: opentelemetry_exporter
  • Outdated: opentelemetry_exporter
  • Outdated: phoenix
  • Outdated: phoenix
  • Outdated: phoenix_live_view
  • Outdated: phoenix_live_view
  • Outdated: swoosh

New (13)

  • Duplicated block (7 lines × 2) (lib/sentry/telemetry/buffer.ex)
  • Medium CVE: EEF-[CVE redacted] (mix.lock)
  • Off-boarding risk: anonymized user #1
  • Outdated: finch
  • Outdated: finch
  • Outdated: finch
  • Projects may be oversized for their cohesion
  • Repeated repair: lib/sentry.ex (lib/sentry.ex)
  • Repeated repair: lib/sentry/callback.ex (lib/sentry/callback.ex)
  • Repeated repair: lib/sentry/client.ex (lib/sentry/client.ex)
  • Repeated repair: lib/sentry/metric.ex (lib/sentry/metric.ex)
  • Repeated repair: lib/sentry/plug_capture.ex (lib/sentry/plug_capture.ex)
  • Repeated repair: lib/sentry/telemetry/scheduler.ex (lib/sentry/telemetry/scheduler.ex)

Changes since last survey

  • 18 commits — 10 feature/other, 8 fixes

By area

  • lib/sentry — 13 commits
  • (root) — 4 commits
  • test/sentry — 1 commit

Notable commits

  • fix: fix(callbacks): wrap Oban callbacks (#1224)
  • fix: fix(callbacks): wrap event pipeline callbacks (#1220)
  • fix: fix(callbacks): wrap log and metric callbacks (#1221)
  • fix: fix(callbacks): wrap plug and phoenix callbacks (#1223)
  • fix: fix(callbacks): wrap traces sampler callback (#1222)
  • fix: fix(config): remove broken enable_logs?/0 (#1229)
  • fix: fix(metrics): attach sentry.timestamp.sequence (#1215)
  • fix: fix(tracing): discard ignored-status transactions as event_processor (#1226)
  • change: chore(deps): Refresh mix.lock files (#1218)
  • change: chore(deps): Refresh mix.lock files (#1234)
  • change: docs: add 13.x to 14.x upgrade guide (#1231)
  • change: docs: updates for 14.0.0 (#1230)
  • change: feat(metrics): report BEAM memory usage as gauges (#1188)
  • change: feat(metrics): report process, atom and port counts in runtime metrics (#1213)
  • change: feat(metrics): report run queue depth in runtime metrics (#1212)
  • change: feat(metrics): report scheduler utilization in runtime metrics (#1189)
  • change: feat(scrubber)!: replace redacted values with [Filtered] (#1227)
  • change: feat(tracing): add option to exclude certain http statuses from tracing (#1217)

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

Survey your own repository

getsentry/sentry-elixir was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.

About this page

  • The score is its most recent published measurement, taken on 3 October 2026 at a pinned commit. It is not a live figure and does not change until the project is measured again.
  • Measured at commit 691774c81031be40a801362d6afdf17101dbbfae — the exact code this score is about.
  • Scored under rubric-2026.10.1 — the same rubric and the same method as every other entry in this index.
  • Measured by watchdog.canine.dev using codehealth-analyzer preprod-8fe32cd45d00.