sentry-symfony: the official Sentry SDK for Symfony applications

A Composer package and a DSN in the environment file

sentry-symfony is described as the official Symfony SDK for Sentry, and the repository description calls it the official Symfony SDK for Sentry. The package is a Symfony bundle, published on Packagist under sentry/sentry-symfony, and the README shows a CI badge and a master code coverage badge pointing at Codecov.

The integration is deliberately small. Installation is a single Composer command:

composer require sentry/sentry-symfony

Configuration is one environment variable. The DSN is added to the .env file, and the README shows the commented block it recommends:

###> sentry/sentry-symfony ###
SENTRY_DSN="https://[email protected]/1"
###< sentry/sentry-symfony ###

The comment markers matter in practice, because Symfony's dotenv loader treats lines between those markers as belonging to the package, which keeps the DSN together and lets the file be regenerated without losing the setting.

The DSN is what tells the SDK which project to report to, and the README links to the Sentry quickstart documentation for where to obtain it. The interesting part of the design is that the SDK is configured almost entirely by the environment, so the same artefact can be deployed to staging and production with different DSN values and no code change.

Manual reporting through a single function

Automatic capture is only half of the story, and the README shows the manual half with a plain function call:

use function Sentry\captureException;

try {
    $this->functionThatMayFail();
} catch (\Throwable $exception) {
    captureException($exception);
}

Two things are worth noting about that snippet. It is a namespaced function imported with a use statement rather than a static method on a class, so calling it does not require instantiating anything. And it catches \Throwable rather than \Exception, so errors that are not exceptions are reported too.

The pattern it supports is the standard one for reporting a failure you have already handled. You catch the throwable, attach whatever context you have, and hand it over. The SDK takes it from there and sends it to the project identified by the DSN.

The README does not document a configuration class, a list of ignored exceptions, a sampling rate or a release tagging option, so the scope of what you can tune is not described in the project README itself. For that, the linked documentation on docs.sentry.io and the Symfony SDK quickstart are the places to look, and the repository also points at Stack Overflow questions tagged with sentry for problems that others have already hit.

Upgrade guides for 3.0, 4.0 and 5.0 are the real documentation

The repository layout explains what a maintained SDK package looks like in practice. At the top level there are composer.json, phpunit.xml, an .editorconfig and a .php-cs-fixer.dist.php for code style, phpstan.neon with a phpstan-baseline.neon, psalm.xml with a psalm-baseline.xml, and codecov.yml. There is also a .craft.yml for the release tooling, a scripts directory, a CHANGELOG.md, an AUTHORS file, an AGENTS.md, a CLAUDE.md and .cursor configuration for tooling.

The three upgrade documents are the most informative files in the tree: UPGRADE-3.0.md, UPGRADE-4.0.md and UPGRADE-5.0.md. Their existence tells you two things at once. First, the package has broken compatibility across majors before, so a 4.x to 5.x jump is not a version bump you can absorb without reading. Second, the maintainers write those guides for users, which is a sign of a package that expects to be upgraded rather than abandoned.

Static analysis is treated as part of the build rather than an afterthought, with both PHPStan and Psalm configured and both carrying a baseline file. A baseline is a record of known issues that are tolerated rather than fixed, and its presence means the project accepts a level of technical debt in exchange for keeping the analysis green.

For anyone integrating this into an existing application, the combination of the upgrade guides, the changelog and the static analysis configuration is a good indicator of how much effort an upgrade will take, and the quickstart documentation covers the SDK-specific configuration that the README leaves out.

A 5.x line with regular releases and a busy commit stream

The release history shows a steady cadence. The recent tags are 5.14.0 on 2026-10-08, 5.13.0 on 2026-08-28 and 5.12.0 on 2026-08-06, and the last push to the repository was on 2026-10-17, so the branch head is only a few days behind the newest release. The repository is not archived, and the licence is MIT with the licence text in the LICENSE file.

Two of the repository topics are worth reading for context. The tag-production topic indicates the package is intended for production use rather than as a toy, and the hacktoberfest topic shows it takes outside contributions during that event, which usually means the issue tracker has been shaped by incoming patches rather than by a long internal roadmap.

The cost of staying current is low here for two reasons. The API surface exposed in the README is one Composer dependency, one environment variable and one function, so a minor release rarely asks you to change application code. And the SDK is versioned independently of the service, so upgrading the package does not force a change on the Sentry side.

What the cadence does not tell you is which Symfony and PHP versions the current release supports. That information is not in the README, and it is the first thing to check before you upgrade, because a bundle that silently drops support for a PHP version you are still running will fail at install time rather than at runtime.

Where the SDK stops and the platform takes over

It is worth being clear about the boundary of this package. The README covers one thing, which is reporting a caught throwable to Sentry from a Symfony application, plus the configuration needed to make that work. It does not describe a client side SDK, a source map uploader, an issue grouping configuration, a performance monitoring setup or a release tagging workflow, and there is no mention of an agent, a CLI or a self hosted collector in the project files.

The practical consequence is that the SDK is one part of an integration. If your team also wants to see frontend errors correlated with backend errors, or wants to trace requests as well as report exceptions, those are separate pieces of the wider Sentry setup that the SDK does not cover.

The second boundary is the maintenance model. A first party SDK is tied to the vendor's release schedule. That is an advantage when the vendor fixes something and pushes a release, and a disadvantage when your application pins a Symfony version the current SDK has already dropped. The upgrade guides for 3.0, 4.0 and 5.0 are the practical tool for that risk, and reading the one matching the version you are moving to is the first step.

Finally, note what the SDK is not. It is not a monitoring agent, it does not sample, it does not deduplicate events and it does not decide what an error is worth. Those decisions live in the Sentry project configuration, which is why the DSN is the only thing the README asks you to configure locally.

Editorial conclusion

Adopt sentry-symfony when you run a Symfony application on Sentry and want the first party integration rather than a hand rolled error reporter, since it is the package Sentry itself publishes and it upgrades alongside the platform. Do not adopt it if you need a client side or a non PHP error source, because the package covers the Symfony server side only. Verify first that your PHP and Symfony versions fall inside the range the installed major supports, that the DSN in your .env file is the one for the right environment, and that the SDK version you take matches the 5.x line, because the repository carries separate upgrade guides for 3.0, 4.0 and 5.0 and each major brought breaking changes.

Frequently asked questions

Official sources

1. getsentry/sentry-symfony on GitHub
2. License: MIT
3. Project website
4. README
5. Releases