Php Airbrake Bundle Laravel Package

Product Decisions This Supports

• Observability vendor strategy for legacy PHP estates. This bundle exists to answer one narrow question: how do we get exceptions from a Symfony 2 application into Airbrake with minimal code? It informs the "keep the lights on" side of the roadmap, not new product investment.
• Build vs. buy vs. glue. The bundle itself is thin integration glue around php-airbrake. It reinforces the right default: buy the error-tracking service, buy or reuse the SDK, and treat framework bindings as commodity code you should not fund in-house.
• Legacy migration scoping. Presence of this dependency is a reliable marker of a Symfony 2.x application in maintenance mode. That makes it useful input for sizing a modernization or re-platforming epic (framework EOL, PHP version ceiling, unmaintained transitive dependencies).
• Framework standardisation decisions. It clarifies a decision you likely need to make anyway: whether error reporting is standardised on one tool across Symfony, Laravel, and non-framework PHP services, or left per-application. A single-vendor, zero-adoption bundle argues for standardising.
• Incident-response readiness. If the answer is "yes, we need alerting on this app," adoption is justified only as a stopgap with a documented replacement date — not as a durable architectural choice.

When to Consider This Package

Consider it only when all of the following hold:

• You have a Symfony 2.x application already instrumented (or committed) to Airbrake, and you want the DI-container wiring rather than hand-rolling a service definition.
• The work is a short, bounded maintenance window — a bug-fix branch or a stabilisation period before migration — not a multi-year commitment.
• Your team has accepted that the dependency is effectively a vendored fork: no upstream activity, no community, no patch stream.
• You are prepared to pin the version and own any security or PHP-compatibility fixes yourself.

Look elsewhere when:

• The stack is Laravel. This is a Symfony bundle; the php-airbrake SDK can be used directly, and the Laravel ecosystem has maintained alternatives. There is no Laravel-specific value here.
• You are on Symfony 3.4+ or PHP 8+. Symfony 2 is end-of-life; the bundle's compatibility surface and the surrounding ecosystem will not keep pace.
• You need a maintained dependency. Zero stars, zero dependents, and a zero package score mean no community backstop and no signal of ongoing stewardship.
• You are starting anything new. Default to a vendor-supported SDK (Sentry, Bugsnag, Rollbar, or Airbrake's own current PHP library) with an actively maintained framework integration.
• You need features beyond exception capture — performance tracing, release health, session replay, or log correlation. This bundle is narrow by design.

How to Pitch It (Stakeholders)

To executives: This is a small piece of plumbing that connects an old Symfony application to Airbrake, our error-tracking service. It is not a product capability and it will not be visible to customers. Its only strategic value is keeping an existing application observable while we decide what to do with it. It has no community adoption and no maintainer activity, so I do not recommend it for any new work. The recommended path is to keep it where it is already in use, set a replacement date tied to the framework migration, and standardise new and rebuilt services on a vendor-supported error-tracking SDK. The cost of adopting it is near zero; the cost of depending on it indefinitely is real.

To engineering: Treat this as a thin Symfony 2 DI bridge over php-airbrake — a handful of service definitions, not a framework. If it is already in the codebase, pin it, document it as unsupported, and add it to the EOL-dependency inventory. If it is not, do not introduce it: use the SDK directly, or better, the SDK for whichever error tracker we are standardising on. For Laravel services, this package is the wrong tool — use the SDK or a maintained Laravel integration. If we must keep it, assign an explicit owner for compatibility patches and a target removal release.

Bottom line: Tolerate, do not adopt. It is a legitimate stopgap for a Symfony 2 application already on Airbrake, and a poor fit for anything else — including anything Laravel.