sentry-symfony

sentry-symfony is Sentry’s officially maintained Symfony integration, wiring the underlying sentry/sentry PHP SDK into Symfony’s kernel, event dispatcher, console, and dependency-injection layers so uncaught exceptions, log records, HTTP requests, and console commands are automatically captured and shipped to a Sentry project. Beyond basic error capture, it adds Symfony-aware distributed tracing spans for Doctrine queries, HTTP client requests, cache operations, and Twig rendering, plus a Monolog handler for routing application logs into Sentry as breadcrumbs or events.

As the official SDK for one external service (Sentry), it’s configured almost entirely through Symfony’s standard bundle configuration (config/packages/sentry.yaml) and DSN, and it tracks Symfony LTS versions (4.4 through current) as first-class support targets.

What You Get

• Automatic exception capture via an event subscriber hooked into kernel.exception, with request/user context attached
• A Monolog handler (src/Monolog) that routes application log records to Sentry as breadcrumbs or captured events based on log level
• Distributed tracing integrations for Doctrine (src/Tracing/Doctrine), the HTTP client (src/Tracing/HttpClient), cache (src/Tracing/Cache), and Twig (src/Tracing/Twig) that produce spans visible in Sentry’s performance UI
• Console command error/performance capture (src/Command, src/Integration) for CLI-triggered errors, not just HTTP requests
• Standard Symfony bundle configuration via config/packages/sentry.yaml, DI compiler passes, and a sentry:test console command to verify setup

Common Use Cases

• Capturing and triaging production exceptions across a Symfony web application without manual try/catch reporting
• Tracing slow Doctrine queries, cache misses, or outbound HTTP calls as part of Sentry’s performance-monitoring product
• Routing existing Monolog log channels into Sentry so error-level logs surface as Sentry issues automatically
• Monitoring cron/CLI Symfony console commands for uncaught errors in background jobs

Under The Hood

Architecture — The bundle is a thin, DI-driven adapter layer over sentry/sentry (the framework-agnostic PHP SDK) rather than reimplementing error capture itself. src/EventListener subscribes to Symfony kernel events (kernel.exception, kernel.request, kernel.terminate) to start/finish a Sentry transaction per request and forward uncaught exceptions to the SDK’s client. src/Tracing/* subpackages each wrap a specific Symfony subsystem — Doctrine DBAL middleware, HttpClientInterface decorators, PSR-6/16 cache decorators, and a Twig extension — instrumenting each with Sentry spans without requiring changes to application code that calls those subsystems normally. src/DependencyInjection/Compiler compiler passes wire all of this together based on the bundle’s YAML configuration, and src/Monolog provides a Handler class implementing Monolog’s HandlerInterface to bridge log records into Sentry breadcrumbs/events. Tech Stack — PHP 7.2/8.0+, built on sentry/sentry (^4.23), guzzlehttp/psr7, and the standard Symfony 4.4-8.0 component range (config, console, dependency-injection, event-dispatcher, http-kernel, psr-http-message-bridge), reflecting Sentry’s commitment to supporting a wide span of Symfony LTS releases simultaneously. Code Quality — 64 PHP source files organized by concern (Tracing subsystems, Serializer, Integration, Monolog, Command, Twig, EventListener), backed by CI-driven tests across the Symfony version matrix and code coverage tracking (visible via the repo’s coverage badge), consistent with an officially maintained vendor SDK rather than a community bundle. API Design — Nearly all configuration happens declaratively via sentry.yaml and a DSN environment variable, with tracing integrations opt-in per subsystem; application code typically needs zero changes to get baseline error capture, and only needs to call the SDK’s captureException()/captureMessage() directly for manual reporting beyond the automatic kernel-level capture.