Other PHP apps

Add Bugsnag to other PHP applications, such as standalone scripts.

This library supports PHP 5.5+, to integrate Bugsnag with older PHP versions (5.2+), check out our legacy integration.


Using Composer

Add bugsnag/bugsnagto your composer.json as follows:

$ composer require "bugsnag/bugsnag:^3.0"

Using a phar package

Download guzzle.phar from the latest release of Guzzle.

Download bugsnag.phar from the latest release of bugsnag-php.

Require guzzle and bugsnag in your application:

require_once "/path/to/guzzle.phar";
require_once "/path/to/bugsnag.phar";

Basic configuration

Create a Bugsnag client object with your Integration API Key:

$bugsnag = Bugsnag\Client::make('YOUR-API-KEY-HERE');

You can find your API key in Project Settings.

On-premise users can set their endpoint by passing a 2nd parameter to this function:

$bugsnag = Bugsnag\Client::make('YOUR-API-KEY-HERE', 'https://your-endpoint.com/');

We also support reading your information from environment variables. If you have BUGSNAG_API_KEY (and optionally BUGSNAG_ENDPOINT) set, we will simply read those values, enabling you to build our client without passing any parameters:

$bugsnag = Bugsnag\Client::make();

If you’d like to configure Bugsnag further, check out the configuration options reference.

Reporting unhandled exceptions

You can ensure that all unhandled errors and exceptions are reported to Bugsnag by registering our exception handler as follows:


Alternatively, you can also ensure that an existing exception handler is not overwritten using the registerWithPrevious method, so that when an exception or error is handled the previously registered exception handler will be called afterwards:


At this point, Bugsnag should be installed and configured, and any unhandled exceptions will be automatically detected and should appear in your Bugsnag dashboard.

Reporting handled exceptions

Reporting handled exceptions can be accomplished as follows:

try {
    // Some potentially crashy code
} catch (Exception $ex) {

When reporting handled exceptions, it’s often helpful to send us custom diagnostic data or to adjust the severity of particular errors. For more information, see reporting handled errors.

Sending diagnostic data

Automatically captured diagnostics

Bugsnag will automatically capture the following data for every exception:

  • A full stacktrace
  • Request information, including ip, headers, URL, HTTP method, and HTTP params
  • Session and cookie data
  • Release stage (production, beta, staging, etc)
  • Hostname

Custom diagnostics

In order to quickly reproduce and fix errors, it is often helpful to send additional application-specific diagnostic data to Bugsnag. This can be accomplished by registering a function to be executed before an error report is sent:

$bugsnag->registerCallback(function ($report) {
        'account' => [
            'name' => 'Acme Co.',
            'paying_customer' => true,

For more information, see the customizing error reports reference.

Logging breadcrumbs

In order to understand what happened in your application before each error, it can be helpful to leave short log statements that we call breadcrumbs. The last 25 breadcrumbs are attached to an error report to help diagnose what events lead to the error. Captured breadcrumbs are shown on your Bugsnag dashboard as a part of the error report.

Leaving breadcrumbs can be accomplished by using leaveBreadcrumb as follows:

$bugsnag->leaveBreadcrumb('Something happened!');

You can optionally attach a type and metadata to a breadcrumb for additional context into the state of the application when the breadcrumb was captured. See the Breadcrumb class for the available types.

    'Something happened!',

And with additional diagnostic metadata:

    'Something happened!',
    ['foo' => 'bar']

The metadata should only be one level deep.

Identifying users

In order to correlate errors with customer reports, or to see a list of users who experienced each error, it is helpful to capture and display user information on your Bugsnag dashboard.

You can set this information as follows:

$bugsnag->registerCallback(function ($report) {
        'id' => '123456',
        'name' => 'Leeroy Jenkins',
        'email' => 'leeeeroy@jenkins.com',

For more information, see configuration options.

Session tracking

Bugsnag can track the number of “sessions” that happen in your application. This enables Bugsnag to provide and compare stability scores between releases to help you understand the quality of your releases. This functionality is disabled by default.

Sessions can be created manually by calling startSession on the Bugsnag client:


Tracking releases

By sending your source revision or application version to us when you release a new version of your app, you’ll be able to see in which release each error was introduced.

Release tracking is built into the Bugsnag PHP library and can be used by calling $bugsnag->build(); with the following parameters:

  • $repository - the source repository for the code which you are releasing.
  • $revision - the source control revision you are currently releasing.
  • $provider - the provider of the git repository. Required for on-premise providers, one of: github-enterprise, bitbucket-server, gitlab-onpremise
  • $builderName - the name of the person or machine who initiated the release. Defaults to whoami.

Release stage, API key, and the application version are automatically detected from your existing configuration.

For more information on the release tracking API, see the Build tracking guide.

Alternatively take a look at our build-tool integrations

Next steps