Django integration guide

Add Bugsnag to your Django applications.

Installation

Using PyPI:

pip install bugsnag

Basic configuration

  1. Configure the library in your Django settings.py:

    BUGSNAG = {
        'api_key': 'YOUR_API_KEY_HERE',
        'project_root': '/path/to/your/app',
    }
    

    You can find your API key in Project Settings.

    If not set, the project_root will default to the current working directory, and api_key will default to the BUGSNAG_API_KEY environment variable.

  2. Add the Bugsnag middleware to the top of MIDDLEWARE in settings.py.

    MIDDLEWARE = (
        'bugsnag.django.middleware.BugsnagMiddleware',
        ...
    )
    

    Note: For versions of Django less than 1.10, use MIDDLEWARE_CLASSES instead of MIDDLEWARE.

If you are running your app using uWSGI, run uwsgi with the --enable-threads option to allow events and sessions to be sent.

Logging configuration

Bugsnag’s handler can integrate with Django’s logging configuration by adding bugsnag.handlers.BugsnagHandler to the application’s logging configuration.

For example, to send any logs that are ERROR and above to Bugsnag (in addition to the existing logging behaviour) the configuration would look like:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,

    'root': {
        'level': 'ERROR',
        'handlers': ['bugsnag'],
    },

    'handlers': {
        'bugsnag': {
            'level': 'INFO',
            'class': 'bugsnag.handlers.BugsnagHandler',
        },
    }
}

Reporting unhandled errors

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

Automatic detection of unhandled exceptions in threads relies on threading.excepthook, which is only supported in Python 3.8 and above.

Reporting handled errors

If you would like to send handled exceptions to Bugsnag, you should import the bugsnag module:

import bugsnag

Then to notify Bugsnag of an error, you can call bugsnag.notify:

bugsnag.notify(Exception("Something broke!"))

You can also pass additional configuration options in as named parameters. These parameters will only affect the current call to notify.

Sending diagnostic data

Automatically captured diagnostics

As well as a full stacktrace for every exception, Bugsnag will automatically capture the following diagnostic data:

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

Custom diagnostics

The metadata field is a dictionary of dictionaries which will be rendered as a tab in a Bugsnag error report. This example would create a special_info tab:

bugsnag.notify(Exception("Something broke!"),
    context="myContext",
    metadata={"special_info":{"request_id": 12345, "message_id": 854}}
)

For more information, see reporting handled errors.

Logging diagnostic data

The BugsnagHandler accepts a special keyword argument to its __init__() function: extra_fields. This is an optional dictionary of extra attributes to gather from each LogRecord and insert into metadata to be attached to Bugsnag error reports.

The keys in the extra_fields dictionary should be tab names for where you would like the data displayed in Bugsnag. The values should be attributes to extract from each log record. The attributes are not required to exist on the log record, and any non-existent attribute will be ignored. For example:

logger = logging.getLogger("your_logger_name")
handler = BugsnagHandler(extra_fields={
    "tab_name": [
        "keyA",
        "keyB"
    ]
})
logger.addHandler(handler)

logger.warning('A warning', extra={
    'keyA': 'abc', # will be added to tab "tab_name"
    'keyB': 'def', # will be added to tab "tab_name"
    'keyC': 'ghi'  # will be ignored by BugsnagHandler
})

This is very useful if you are assigning context-specific attributes to your LogRecord objects, as described in the python logging cookbook.

Session tracking

Bugsnag tracks the number of “sessions” that happen within your application. This allows you to compare stability scores between releases and helps you to understand the quality of your releases.

Sessions are captured and reported by default. This behavior can be disabled using the auto_capture_sessions configuration option.

Using this option, Bugsnag will report a session each time a request is made to the server.

If you want control over what is deemed a session, rather than using the auto_capture_sessions option, you can call Bugsnag.start_session when appropriate for your application.

Identifying users

The user field is information about the person currently using your application. It should be a dictionary containing id, email, and/or name.

By default it is automatically populated with the HttpRequest.user. To override this behaviour see customizing error reports.

Logging breadcrumbs

In order to understand what happened in your application before each crash, it can be helpful to leave short log statements that we call breadcrumbs. A configurable number of breadcrumbs are attached to each error report to help diagnose what events led to the error.

Automatically captured breadcrumbs

By default, Bugsnag captures the following events as breadcrumbs:

  • Error reports

  • HTTP requests

This can be controlled using the enabled_breadcrumb_types configuration option.

Leaving manual breadcrumbs

You can use the leave_breadcrumb method to log potentially useful events in your own applications:

bugsnag.leave_breadcrumb("Something happened!")

Additional data can also be attached to breadcrumbs by providing the optional type and metadata parameters. For more information and examples for how custom breadcrumbs can be integrated, see customizing breadcrumbs.

Next steps