Monolog Bugsnag Bundle Laravel Package

Technical Evaluation

Architecture fit — poor at the package level, plausible at the class level. The artifact is a Symfony bundle (*Bundle, DependencyInjection/, service definitions) wrapping a Monolog 3 handler for Bugsnag. Laravel has no bundle auto-registration mechanism; bundle packages are inert in an Illuminate application. Composer will install it, but the only piece of the package a Laravel app can actually use is the handler class itself. Everything else — extension class, DI config, Symfony service wiring — is dead weight, yet still pulls symfony/framework-bundle (and its DI/HttpKernel config surface) into our dependency graph. For a Laravel 10/11 codebase whose logging stack is config/logging.php → LogManager → Monolog 3, that is an architectural mismatch, not a fit.

Integration feasibility — technically trivial, organizationally awkward. The usable work is roughly a 40–80 line Monolog handler: extend Monolog\Handler\AbstractProcessingHandler, take a Bugsnag\Client in the constructor, call notifyException() in write(), optionally honor bubble and a minimum level. Wiring it into Laravel is a custom channel in config/logging.php and a LOG_STACK entry. That is a half-day of engineering plus tests. The hard part is not building it; it is justifying a third-party 1-star dependency to do it.

Technical risk — low runtime blast radius, high governance blast radius.

Key questions to resolve before any go decision:

1. Does bugsnag/bugsnag-laravel (current major) already ship a Monolog 3-compatible handler? If yes, this package has no reason to exist for us and the evaluation ends. If no, the gap is real — but is it a gap worth a dependency, or a 50-line shim?
2. What is the actual diff between this handler and Bugsnag's official handler / bugsnag/bugsnag-psr-logger? If it is a composer.json constraint bump plus a namespace change, the "product" here is near-zero.
3. Can legal resolve NOASSERTION, or is the answer a hard no? This is a go/no-go gate, not a risk to be tracked.
4. Who owns the code if we adopt — and what is the exit trigger (e.g. upstream Monolog 3 support landing, at which point we delete this)?
5. What data classification flows into Bugsnag payloads (exception messages, stack context, breadcrumbs, request bodies), and does the handler respect Bugsnag's PII scrubbing and discardClasses config we already use?

TPM read: Score 0.005 with 1 star and 0 dependents is an accurate signal — this is not a component to adopt, it is a reference implementation. Its value to us is as a known-good example of the Monolog 3 handler contract, and as evidence that a compatibility gap exists. Treat it as a spike input, not a dependency.

Integration Approach

Stack fit. Laravel 10+ (Monolog 3) is the only reason this package is interesting. On Laravel 9 (Monolog 2) it is irrelevant. Our target stack — Laravel 11, PHP 8.2/8.3, Bugsnag via bugsnag/bugsnag-laravel, Monolog 3 through the framework — means the handler interface we need is Monolog\Handler\AbstractProcessingHandler with Bugsnag\Client as the collaborator.

Recommended path (in preference order):

1. Use the official SDK's channel. Confirm bugsnag/bugsnag-laravel supports Monolog 3. Wire Bugsnag as a stack/channels target in config/logging.php, keep exception reporting on bootstrap/app.php → withExceptions() so uncaught exceptions and report() go through one path. Zero new code, vendor-backed, license-clean. This should be the default answer.
2. Internal shim, ~50 LOC, own the copyright. If the vendor handler genuinely lacks Monolog 3 support: write App\Logging\BugsnagHandler extends AbstractProcessingHandler, wrap Bugsnag\Client, catch and Log-swallow transport exceptions, register it as a custom channel via Log::extend/a channel factory, and unit-test that (a) handle() never throws, (b) level filtering works, (c) bubble=false stops propagation. Cost: 1–2 engineer-days including tests. This is the recommended path if option 1 fails.
3. Fork this repo into our GitHub org and pin it. Only if legal approves the license and we want to preserve the Symfony bundle wrapper for a future Symfony service. For a Laravel-only roadmap this is unjustifiable overhead.
4. Install this package as-is into Laravel. Not recommended: pulls symfony/framework-bundle for a class we could write in an afternoon, inherits an unresolvable license, and creates a dependency with no maintainer to page.

Migration path if we already have log-to-Bugsnag behavior: none needed if we standardize on the official channel. If we are currently on a custom handler (or Monolog 2 pinning), the migration is: bump to Monolog 3, verify the channel still receives records, verify report() path still delivers, verify breadcrumbs and release-stage tags survive. Keep the old channel config behind a feature flag for one release cycle.

Compatibility and sequencing.

Sequence the work after the Monolog 3 upgrade lands, not alongside it — do not couple two failure domains (framework logging upgrade + new error transport) in one release.

Operational Impact

Maintenance. As a dependency, this package has no maintenance model: one maintainer, no visible release cadence, no dependents to surface breakage, and a Feb-2024 last release that will silently rot as Monolog and Bugsnag majors move. As an internal 50-line shim, maintenance is near-zero — it implements a stable interface (AbstractProcessingHandler) against a stable API (Client::notifyException). The shim is objectively cheaper to own than the dependency is to babysit, which is the central TPM argument against adoption.

Support. No vendor, no SLA, no security contact. If a CVE lands in the handler logic (e.g. payload construction, header capture), we are the only responders. That is acceptable for code we wrote and reviewed; it is not acceptable for code we pulled from an unaffiliated 1-star repository whose license we cannot name.

Scaling. Handler-level cost is negligible relative to the Bugsnag HTTP flush, but three scaling behaviors need explicit design:

• Event volume / cost. Routing all Log::error traffic to Bugsnag multiplies event counts and Bugsnag plan costs. Enforce a level floor (error and above) and use Bugsnag::setBatchSending/notification throttling. This is a budget decision, not an engineering one — TPM must set the policy.
• Synchronous HTTP in the request path. Bugsnag delivery on the hot path adds tail latency. Confirm the client queues and flushes at terminate; if not, wrap delivery in a queued job or terminate hook. Same concern applies equally to the official SDK.
• Noise. Unhandled-exception reporting and log-error reporting will double-count the same event. Deduplicate by keeping exception reporting on Laravel's withExceptions path and reserving the log channel for caught-and-logged error/critical records.

Failure modes to design against.

1. Recursive failure — handler throws while handling an error. Mitigation: catch-all inside write(), never bubble exceptions; log the transport failure to the fallback (stderr/local file) channel.
2. Silent data loss — Bugsnag unreachable or API key misconfigured at deploy; errors vanish with no alarm. Mitigation: synthetic check that emits a tagged test event per environment on deploy, plus a heartbeat/alert on the Bugsnag project's event count.
3. PII leakage — exception context, request bodies, or breadcrumbs carrying customer data to a third party. Mitigation: apply Bugsnag's filter callbacks and a dontReport allowlist; audit payloads in the shadow sprint.
4. Dependency drift — abandoned package pinned to a stale Monolog constraint blocks a future framework upgrade. Mitigation: pin with a documented expiry date and an owner; this is exactly the debt the shim avoids.
5. Queue/worker blindness — CLI and queue contexts lack the request metadata, producing unactionable events. Mitigation: set release_stage, job class, and queue name as metadata via a middleware/JobProcessing listener.

Ramp-up. Engineering ramp is trivial — half a day for anyone who has wired a custom Monolog channel; the interface is well known and the shim is small. The real ramp cost is organizational: legal exception process for an ambiguous license (days-to-weeks, often an outright no), security review of an unaudited dependency, and the ongoing cognitive tax of a pinned, unmaintained package in the graph. Total cost of ownership strongly favors either the official SDK channel or a self-owned handler over adopting this package.

Recommendation: Do not take a production dependency on mrandmrssmith/monolog-bugsnag-bundle. Close the underlying need — Monolog 3 → Bugsnag delivery on Laravel 10+ — via the official Bugsnag Laravel SDK if it supports Monolog 3, else via a ~50-line internally owned handler. Use this repository only as a reference implementation during the spike, and record it in the decision log as evaluated and rejected: license unresolved, zero adoption, Symfony-shaped for a Laravel stack.