Airbrake Bundle Laravel Package

Technical Evaluation

Framing mismatch is the first finding. The request describes a "Laravel/PHP package," but i22/airbrake-bundle is a Symfony bundle. That distinction is not pedantry — it determines whether there is anything here to adopt at all. A Symfony bundle's entire contribution is a Bundle subclass, a DependencyInjection/Extension that hydrates a service container from a config tree, and compiler passes registering an Airbrake client and (typically) a Monolog handler. Laravel has no bundle, extension, or compiler-pass concept; its analogues are service providers, config/*.php arrays, and the Monolog LogManager channel stack. None of the package's actual value-add transfers to Laravel. What transfers is the wrapped notifier (airbrake/airbrake-php / phpbrake), which is an ordinary Composer library and can be wired into a Laravel service provider in about a day.

Architecture fit — poor as a dependency, adequate as a specification. Treat this repository as documentation of how to wire Airbrake into a Symfony-style framework, not as an installable artifact. On Laravel it is out of scope by construction.

Integration feasibility — feasible only as a reference implementation. The realistic path is to read the bundle's config keys and handler wiring and reproduce ~150 lines of it as a Laravel service provider plus a custom Monolog handler. Installing the bundle itself into a modern Laravel app is not viable.

Technical risk — high, and dominated by project-health and vendor signals rather than code quality.

• Zero stars, zero dependents. No evidence of production validation, no community debugging surface, no one finding bugs ahead of us. Every issue we encounter, we own alone.
• Abandonment and version pinning. I22 bundles of this vintage target Symfony 2.x/3.x with tight symfony/* and PHP constraints. Composer will almost certainly refuse to install it alongside a modern Laravel (Symfony 6/7 components, PHP 8.2+), and there will be no upstream fix.
• Vendor risk on Airbrake.io itself. Airbrake's PHP notifier is the least-maintained of the major SDKs, and error-monitoring has consolidated heavily toward Sentry. Committing incident-response infrastructure to a shrinking vendor is a multi-year decision being made incidentally by a one-day integration task — which is backwards.
• Security and PII. Error payloads carry stack traces, request params, and frequently session or auth context. The bundle's era predates widespread default scrubbing, so filter and allowlist configuration must be authored and tested by us. Project keys are write-only ingest keys, but must still live in secret storage, not the repo.
• Synchronous reporting in the request path by default means an Airbrake API slowdown becomes our latency incident.

Key questions for the team:

1. Do we actually operate any Symfony services, or is "Laravel/PHP" shorthand for a mixed estate? If pure Laravel, this package is out of scope by construction.
2. Is Airbrake.io already a sanctioned vendor with an active contract, or is this a greenfield observability decision? If greenfield, why not Sentry?
3. What are our budget, retention, and quota requirements, and does Airbrake's pricing fit them?
4. Do compliance constraints (PII in payloads, EU data residency) conflict with the notifier's default behavior?
5. Who owns a fork if we adopt the notifier and it needs a patch?

Integration Approach

Stack fit. Assume Laravel 10/11 on PHP 8.2+. The bundle is a non-starter. The viable target is airbrake/airbrake-php (or airbrake/phpbrake) behind a Laravel service provider. Note that phpbrake depends on Guzzle — check the Guzzle major version against everything else in the app (AWS SDK, Stripe, social auth). Guzzle 6/7 splits are the single most common dependency conflict in Laravel estates.

Migration path — three options, in preference order:

1. Adopt the notifier directly. Bind a singleton Airbrake\Notifier in an AirbrakeServiceProvider, add a custom Monolog handler on the error/critical channels, and hook Exceptions\Handler::report() for uncaught exceptions. No bundle dependency. ~1–2 engineer-days including tests.
2. Fork-and-strip. Copy the bundle's config schema and handler wiring into an internal package. Only worth it if we also run Symfony and want one shared contract across both frameworks — otherwise it is maintenance for nobody's benefit.
3. Replace the vendor. If the Airbrake relationship is not already established, run a short bake-off against sentry/sentry-laravel, which is first-party, actively maintained, and installs with one command. On total cost of ownership this will very likely win.

Compatibility. Verify PHP constraint, symfony/* component versions, Guzzle major, and Monolog 2 vs 3 (HandlerInterface signature changed). If some service in the estate sits on Symfony 4.4 or below the bundle might install there — but that does nothing for the Laravel app that motivated the request.

Sequencing.

1. Confirm the framework estate and whether Airbrake is already contracted (one day, no code). This is a gate, not a formality.
2. If proceeding: POC in a non-production Laravel service — install the notifier, throw a synthetic exception, verify it lands in Airbrake with correct environment and deployment tagging.
3. Author the PII scrub list and test it against a request containing auth headers and form bodies.
4. Wire the Monolog handler and Handler::report(); add a feature test asserting a thrown exception produces exactly one report.
5. Roll out behind an env flag to staging, then a single production service, before anything estate-wide.
6. Only then decide whether a shared internal package is warranted.

Operational Impact

Maintenance. Zero upstream. If we adopt either the bundle or a thin wrapper, we are the maintainers. Budget a recurring ~2–4 hours per quarter for dependency bumps and notifier drift, plus the real cost: when a new PHP or Laravel major lands, someone must verify the notifier still runs. A first-party SDK makes that check free.

Support. No vendor SLA on the bundle, no maintainer responsiveness expectation, no security advisory channel we are subscribed to. Airbrake support covers the service, not this integration. The escalation path for "errors aren't showing up" is entirely internal — a bad place to be, given that error reporting fails silently by design.

Scaling. Two pressure points. First, the notifier posts synchronously by default; at high request volume a slow Airbrake endpoint adds tail latency and can cascade into worker exhaustion under PHP-FPM. Mitigate with queue-backed async reporting or the notifier's async/curl settings, and set an aggressive connect timeout (sub-second). Second, quota burn: a retry loop or one noisy exception can exhaust the monthly quota in minutes, at which point reporting stops and we are blind during precisely the incident we need visibility into. Enable sampling, de-duplication, and a hard rate limit before production rollout.

Failure modes to design for:

• Silent drop. Airbrake unreachable → exceptions vanish, alerting never fires, team believes the service is healthy. Run a scheduled synthetic canary exception that alerts if the dashboard stops receiving it.
• Request-path blocking. Ingest timeout stalls user requests. Enforce timeout plus try/catch around all reporting.
• Recursive failure. Notifier throws inside the exception handler → blank 500s or loops. Fail open, always.
• PII leakage. Unscrubbed params land in a third-party SaaS. Highest-severity risk, and the one most likely to be surfaced by legal rather than engineering.
• Key rotation gap. Rotating the project key without updating every service's env silently zeros out reporting.

Ramp-up. Low for any PHP developer — the API is notify($exception). The real ramp-up is organizational: teaching the team to triage in Airbrake rather than tailing storage/logs/laravel.log, defining what constitutes an alert versus a trend, and assigning ownership of the dashboard. That is a 2–4 week adoption curve regardless of SDK, and it argues for choosing the SDK with the better onboarding documentation — which is not this one.

TPM recommendation. Do not adopt i22/airbrake-bundle as a dependency. It is a Symfony-only, unmaintained, zero-adoption artifact that cannot install into a modern Laravel application and whose value-add does not port. Use it at most as documentation for wiring the underlying notifier into a service provider. More importantly, force the vendor decision to the surface before spending engineering time: the adapter is commodity and the vendor contract is the product decision. If Airbrake is not already contracted, a first-party Sentry integration will be cheaper to build, cheaper to run, and materially lower-risk — and if we are moving off Airbrake, this repository usefully confirms the coupling surface is roughly a handler plus two config keys, which makes leaving a one-to-two-day swap rather than a strategic lock-in.