bugsnag-laravel: reporting Laravel exceptions to Bugsnag

A framework integration, not a general PHP error library

The scope here is narrow on purpose. This package is the notifier for one framework, Laravel, and for its micro-framework sibling Lumen, and the README says both are supported. What it does is deliver application errors to the Bugsnag service, and the two paths it covers are the ones that matter in a web application. The first is automatic: unhandled exceptions and crashes are reported without anyone writing a call. The second is manual: an exception you catch yourself can still be sent, which the documentation covers under reporting handled exceptions. That second path is where most of the design decisions live, and it is worth being clear that the package is a client, not a monitoring system. It does not decide what an error is worth, it does not retain anything, and it does not alert anyone. It formats an event and posts it to a service that does. That boundary matters when you are evaluating it, because the questions you should be asking about retention, filtering and alerting are answered by Bugsnag rather than by this repository.

The unhandled path is automatic, the handled path needs a deliberate call

The feature list names three things: automatically report unhandled exceptions and crashes, report handled exceptions, and attach user information and custom diagnostic data to determine how many people are affected by a crash. The third item is the one with real engineering content, because a crash count is only interesting if you know how many distinct users hit it, and a stack trace alone cannot tell you that. The getting started sequence puts the handled case first among the practical steps, with the reporting API spelled as Bugsnag::notify(). The one line to remember is this:

Bugsnag::notify()

The point of a separate notify() call is that it does not change control flow. Catching an exception and rethrowing it, or catching it and returning a fallback, both suppress the automatic path, because from the framework's point of view the exception never escaped. Wrapping the catch in a notify() call preserves the information while keeping your own error handling. The cost is that it is a convention, and conventions are only as good as the review culture around them. A codebase that adds notify() in some catch blocks and not others produces error data that reflects coding habits rather than failure rates, which is a subtle way to make a dashboard lie.

Setup goes through the integration guide, not through a package snippet

The getting started steps are short and they are all links rather than code. You create a Bugsnag account, then complete the instructions in the integration guide for Laravel or for Lumen, then report handled exceptions, then customize using the configuration options. The absence of a composer require line in the README is deliberate rather than an oversight, because a Laravel package normally needs more than a require statement to work: it needs a service provider registered, a config file published, an API key in the environment, and the notifier hooked into the framework's exception handling. The integration guide is where those steps live. The repository supports that guide with an example directory containing a working application per framework version, and the versions covered there span Laravel 5.2, 5.8, 6, 7, 11, 12 and 13 along with Lumen 5.2, 5.8, 6 and 7. That spread is the most useful thing in the repository for a team trying to work out what the integration looks like on their own version, and it also tells you how wide the compatibility claim is.

Configuration options are the surface you will actually tune

After installation, the documentation points you at the configuration options page, and that page is where the behaviour of the notifier is decided. The README mentions customization as the fourth and final getting started step, which tells you the defaults are expected to work for a standard application and that the interesting cases are exceptions to them. The kind of things that live in a Laravel notifier's configuration are the ones a developer only discovers after a week of noisy dashboards: which environments are excluded, which release is considered current so that stack traces point at the right line, which paths should be filtered out as noise, and what metadata to attach to each event. The user and custom diagnostic data that the feature list refers to is what makes it possible to answer how many people are affected, and that data has to come from somewhere the application knows, such as the authenticated user on the request. The repository does not document the individual option names, so the configuration page rather than the README is the reference you need.

The alternative is your own exception handler, with a different ownership model

There is a real alternative to this package, and it is not another monitoring vendor so much as a different approach to the problem. Instead of installing a framework integration, you can register your own exception handler in the service provider, catch everything the framework hands you, and forward the event to whatever collector you choose, including one you operate yourself. The difference in approach is where the code and the data live. A framework integration such as this one is short, maintained alongside the framework version, and knows about Laravel's exception lifecycle, so it captures the request context, the user and the route without you writing that glue. A hand written handler is more code for you to own and test, and it has to be re-checked on every Laravel upgrade, but it lets you decide the payload and the destination rather than accepting a vendor's format. If the decision about which service to use is still open, writing that handler first is a way to discover exactly what data you need before you commit to a vendor.

Version 1 stays on a branch for the Laravel 4 era

The package has a branch that still matters to somebody. The README has a section for people looking for Laravel 4 support, and it points at the 1.7 branch, where v1 of the Laravel package lives. So the current line is v2, and the older line is deliberately parked rather than deleted, which is a good thing for a team still running an old application but a trap for anyone browsing branches and picking one at random. The release history makes the split visible: v2.31.0 on 2026-09-10, v2.30.0 on 2026-04-08 and v2.29.0 on 2025-02-26. The last push was on 2026-09-10, the same day as the v2.31.0 release. The repository root carries a CHANGELOG.md and an UPGRADING.md, which together are what you want to read before bumping a major version, plus a SECURITY.md for disclosure policy. A Gemfile sits at the root alongside composer.json, a leftover from the Ruby era of the project's tooling, and is harmless but worth knowing about if you are looking for the authoritative dependency manifest.

The test setup is a Makefile around Composer scripts

The developer workflow is a thin Makefile over Composer, and it tells you how the project is tested. The default target is test, and the build target installs the dependencies with composer install while update runs composer update. The test target delegates to composer test, and the coverage targets extend that with a --coverage-html=build/coverage flag, with view-coverage opening the generated HTML report. A help target parses the target descriptions and prints them, which is why every target carries a double hash comment. The repository also has a features/ directory alongside phpunit.xml.dist, so there is a mix of unit and feature level testing in the suite, and a scripts/ directory for the supporting automation. Two files in the root are worth a look before you contribute: CONTRIBUTING.md, which the README points to for how to build, test and release, and SECURITY.md, which covers how to report a security problem in the notifier. The licence is stated as free software released under the MIT License, with LICENSE.txt carrying the terms.

Editorial conclusion

bugsnag-laravel is a sound choice for a Laravel or Lumen team that has already chosen Bugsnag as its error monitoring service and wants the framework integration rather than a hand written handler, and for a team moving up from version 1 who needs the Laravel 4 era support dropped. It is the wrong tool if you are still deciding between monitoring services, because this package only speaks to one of them, and it is the wrong tool if your priority is self hosted collection, because the data leaves your infrastructure. Before adopting it, work through the configuration options page rather than accepting the defaults, decide early whether the notify() call for handled exceptions will be used consistently or ignored, and check the example application for your own Laravel version under the example directory, since that directory covers Laravel 5.2 through 13 and Lumen 5.2 through 7.

Frequently asked questions

Official sources

1. bugsnag/bugsnag-laravel on GitHub
2. License: MIT
3. Project website
4. README
5. Releases