Airbrake Bundle Laravel Package

Product Decisions This Supports

• The vendor decision, not the adapter decision. This package is a ~200-line Symfony adapter around Airbrake.io. Adopting or rejecting it is commodity; the real product decision it surfaces is whether Airbrake.io is our sanctioned error-tracking vendor, or whether we standardize on Sentry/Rollbar/a broader OpenTelemetry pipeline. Use this evaluation to force that conversation rather than to answer it.
• Feature-level: error visibility for a Symfony service. If a Symfony service in the estate has no error tracking today, this is a low-effort path to a dashboard. It is not the thing to standardize an organization on.
• Roadmap: reliability maturity. Error tracking is a prerequisite for on-call rotations, SLIs/SLOs, error budgets, and postmortems. Choosing the integration now determines the surface for later work — release tagging, deploy correlation, Slack/PagerDuty routing.
• Build vs. buy vs. vendor-in. Zero stars, zero dependents, and a Symfony 2.x/3.x-era constraint set mean this should be treated as reference code. The decision it supports is "reproduce ~150 lines in our own service provider" — not "add to composer.json."
• Migration scoping. If Airbrake is a candidate to leave (the market has consolidated toward Sentry), this tells us the coupling surface is small and the swap is roughly one to two engineer-days. That de-risks the "leave Airbrake" option and lowers the cost of deferring the decision by a quarter.
• Laravel framing correction. The request frames this as a Laravel package; it is a Symfony bundle. The bundle/extension/compiler-pass machinery does not transfer to Laravel's service-provider/config/LogManager model. If the estate is pure Laravel, this is out of scope by construction — and that is itself a useful portfolio finding.

When to Consider This Package

Consider it only when all of the following hold:

• The application is Symfony, not Laravel. On Laravel, use the underlying airbrake/airbrake-php notifier behind a service provider instead.
• We already hold an active Airbrake.io contract and are not consolidating vendors this year.
• Our Symfony and PHP versions fall inside the bundle's composer.json constraints — verify this before assuming compatibility; it will likely exclude modern Symfony 6/7 and PHP 8.2+.
• We are prepared to fork or vendor the code: read it, pin the commit, and own it. The adoption criterion is "small enough to audit and maintain ourselves," not "the maintainer will respond."

Look elsewhere when:

• Maintenance signal matters. Zero stars and zero dependents is not proof of bad code, but it is proof of no community — nobody is finding bugs before we do, or fixing them after.
• We are on Laravel, or on a Symfony version outside the constraint range.
• We have not yet chosen a vendor. Run a short bake-off (Sentry and Rollbar both ship well-maintained first-party Symfony SDKs) rather than letting an abandoned adapter pick the vendor by default.
• Compliance or security review is in scope. An unmaintained dependency on the global exception path needs a documented risk acceptance; a first-party SDK clears review faster.
• We want vendor-portable telemetry. OpenTelemetry-native instrumentation gives portability; a vendor-specific bundle does the opposite.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source connector that plugs the Airbrake.io error-monitoring service into Symfony applications. The connector itself is low-value and effectively unmaintained — no community, no downstream users — so we should not depend on it. The decision worth your attention is the vendor: error tracking is table stakes for running a production service with an on-call commitment, and it is a recurring SaaS cost. Recommendation is to make a deliberate vendor choice — Sentry is the default candidate on ecosystem health — rather than adopting this package by default, and to budget the integration as a one-to-two-day engineering task either way. We also need to confirm whether our estate is Symfony, Laravel, or mixed, since this package only applies to the first.

For engineering: This is a thin Symfony bundle wrapping Airbrake's PHP client — config plus a handler wired into the framework's exception path. It probably works, but with zero stars and zero dependents, treat it as sample code: read it, and if we stay on Airbrake, copy the handler into our own bundle where we control the Symfony version constraints and the maintenance. If we are on Laravel, it does not apply — bind airbrake/airbrake-php in a service provider, add a Monolog handler on the error/critical channels, and hook Exceptions\Handler::report(); roughly one to two engineer-days including tests. Watch three operational traps regardless of path: synchronous reporting in the request path (set an aggressive connect timeout, fail open), PII in payloads (author and test a scrub list — this is the highest-severity risk), and silent drops (add a scheduled synthetic canary so we learn when reporting stops). If we have not picked a vendor, spend half a day comparing the first-party Sentry and Rollbar SDKs before committing; the swap cost is small but non-zero, and the vendor decision outlives the adapter.

Bottom line: Do not adopt as a strategic dependency. Use it as a scoping artifact for the vendor decision, and only reach for it if we are already committed to Airbrake on Symfony and are prepared to own the code.