Php Airbrake Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the integration layer — and the answer is “neither, choose a vendor SDK.” This package is a config block, a DI extension, and an exception listener. The integration itself is commodity work; the product decision worth making is which error backend the org standardizes on, because that determines cost, coverage, and vendor leverage. Treat this repo as a data point that Airbrake-in-Symfony can be wired, not as the wiring to adopt.

• Observability roadmap scoping — deliberately narrow. It supports one slice: uncaught exception capture with environment tagging and alert routing. It does not support modern roadmap expectations — breadcrumbs, tracing/performance, release health, queue/console error capture, session replay — so it must not be used to mark “error monitoring: done.” If anything, its age is the argument for accelerating the roadmap item.

• Framework-reality check as a decision input. Despite the “Laravel/PHP package” label, this is a Symfony 2 bundle targeting PHP 5.6/7.x-era runtimes. For a Laravel product that is a non-starter without a fork (3–5 engineering days before any error lands). This is a genuine PM input: packages are frequently mislabeled in dependency inventories, and an “available integration” that requires a fork is a build decision, not a buy decision.

• Legacy portfolio triage — keep / contain / replace. 0 stars, 0 dependents, 0 score is a signal, not a footnote: nobody is validating compatibility, nobody is filing CVEs, nobody has hardened it in production. For an inherited Symfony app with a signed Airbrake contract, that supports a timeboxed “contain and replace” decision rather than indefinite reliance.

• Risk/coverage tradeoff framing. The choice is between a free, unowned wrapper that captures exceptions only, and a maintained SDK (Sentry/Bugsnag/Rollbar, or Airbrake’s own maintained bundle/notifier) that delivers release tracking, performance visibility, and vendor security response for roughly the same integration effort. Framing that as “same cost, more coverage, less ownership” is the PM’s core job here.

• Use case it genuinely fits: a short, reversible stopgap on an existing Symfony 2.x/3.x app where Airbrake is already contracted and changing vendor is explicitly out of scope for the quarter.

When to Consider This Package

Consider it only when all of the following hold:

• You are on a legacy Symfony version (2.x/3.x) with no near-term framework upgrade on the roadmap — and you have verified the listener still matches the kernel’s exception API (the ExceptionEvent::getException() pattern broke at Symfony 4.x).
• Airbrake is an existing, contracted, or mandated vendor, not an open evaluation.
• You need a reporter this sprint and accept that you will vendor, fork, or pin it and name an owner, because upstream is dormant.
• The affected surface is internal or low-blast-radius, and a silent failure of the reporter is an acceptable outcome.
• You have a startup self-test or canary, because a deprecated endpoint or rotated key fails silently.

Look elsewhere when any of the following hold:

• New build, or Laravel. This is not a Laravel package. Laravel pins Symfony 5/6/7 components; this targets the Symfony 2 era. There is no autoloadable path in. Do not let an inventory entry saying “Laravel/PHP package” drive the decision.
• Modern Symfony (4+/5+/6+), PHP 8.x. Assume incompatible until proven otherwise; a single fatal at first exception is a worse outcome than no integration.
• You want maintained, first-party-quality support. Default to sentry/sentry-laravel or sentry/sentry-symfony for breadth; Bugsnag and Rollbar are comparable. If Airbrake is fixed, use Airbrake’s own maintained notifier (airbrake/phpbrake) behind a thin provider plus a Monolog handler — not this bundle.
• You need release tracking, deploy correlation, alert SLAs, queue/console coverage, or vendor security responsiveness. A 0-star, 0-dependent repo cannot credibly promise any of these.
• You would be the first and only dependent. Being the de facto maintainer of a dependency is a recurring product cost, not a free win — budget 1–2 days per quarter minimum, plus unbounded incident time if ingestion silently breaks.

How to Pitch It (Stakeholders)

To executives: This is a small, free wrapper for an old part of the stack — not a platform decision, and it should not be funded as one. The real decision is which error-monitoring vendor we standardize on, because the integration layer is trivial while the vendor choice determines cost, coverage, and how fast we detect and fix production incidents. My recommendation: do not adopt this as a foundation for any new or customer-facing work. Permit it only as a timeboxed stopgap with a named owner and an explicit removal date, and route the same effort to a maintained SDK that gives us release tracking and performance visibility for roughly the same integration cost.

To engineering: It is a config block plus an exception listener — near-zero adoption cost, but the cost is ownership. Zero stars, zero dependents, zero issue triage means no upgrade path, no CVE response, no PHP 8 guarantee, and no peer corpus to troubleshoot against; mean time to diagnosis would be entirely internal. There is also a labeling trap: it is a Symfony 2 bundle, not a Laravel package, so on our stack it requires a fork (replace the DI extension, YAML config, and kernel listener) — realistically 3–5 engineering days before the first error lands, which makes it a build project dressed as a dependency. If we proceed anyway: fork it, pin it, document the owner, add a startup self-test so ingestion can't fail silently, scrub PII before transmission, dispatch asynchronously with a hard timeout so the reporter never sits on the request path or throws into application code, and set a removal date.

Decision framing: Low adoption cost on legacy Symfony, low strategic value, non-trivial ownership and compatibility risk, and a category mismatch for Laravel — approve as a narrow, reversible stopgap at most; reject as a foundation. The higher-leverage move is to standardize on a maintained SDK and spend the saved days on error coverage that actually pages someone.