Docs Platforms Python Django Configuration options
Smartbear.com Start Free Trial
BugSnag is now Insight Hub – we're making some changes to how the product looks, but this won't impact the way you use BugSnag or any of your integrations.

Configuration options

All available options for configuring your integration with BugSnag.

api_key

Your BugSnag API key (required)

bugsnag.configure(api_key="1234API-KEY")

You can find your API key in your project’s settings (shortcut: gs) in the dashboard.

app_type

Specify the app component or configuration currently active. This allows filtering and grouping events by the worker queue, HTTP router, and more. It is set to None by default.

bugsnag.configure(app_type="email_queue")

app_version

If you want to track which versions of your application each exception happens in, you can set app_version. It is set to None by default.

bugsnag.configure(app_version="2.5.1")

asynchronous

By default, requests are sent asynchronously to BugSnag. If you would like to block until the request is done, you can set asynchronous:

bugsnag.configure(asynchronous=False)

auto_capture_sessions

Set to false if you would like BugSnag not to automatically capture sessions.

bugsnag.configure(auto_capture_sessions=False)

auto_notify

By default, we will automatically notify BugSnag of any fatal exceptions in your application. If you want to stop this from happening, you can set auto_notify:

bugsnag.configure(auto_notify=False)

When using the leave_breadcrumbs log filter, log messages will be recorded as breadcrumbs. By default, BugSnag will record INFO messages or greater (more severe), you can change this behavior by setting the breadcrumb_log_level:

bugsnag.configure(breadcrumb_log_level=logging.WARNING)

delivery

The delivery property is a generic way to send a serialized payload to BugSnag. By default, if requests is installed, the RequestsDelivery class is used to deliver error reports, otherwise UrllibDelivery is used.

To enforce using urllib2/ urllib3:

from bugsnag.delivery import UrllibDelivery

bugsnag.configure(delivery=UrllibDelivery())

To use a custom delivery, implement the Delivery class:

from bugsnag.delivery import Delivery

class SomeSpecialDelivery(Delivery):

    def deliver(self, config, payload):
        send_to_my_queue(config.endpoint, config.proxy_host, payload)

bugsnag.configure(delivery=SomeSpecialDelivery())

enabled_breadcrumb_types

By default BugSnag will automatically add breadcrumbs for common events whilst your application is running. Set this option to configure which of these are enabled and sent to BugSnag.

from bugsnag import BreadcrumbType

bugsnag.configure(enabled_breadcrumb_types=[BreadcrumbType.ERROR, BreadcrumbType.LOG])

Automatically captured breadcrumbs can be disabled by providing an empty list:

bugsnag.configure(enabled_breadcrumb_types=[])

The following automatic breadcrumb types can be enabled:

Captured errors

BreadcrumbType.ERROR breadcrumbs are left when an error event is sent to the BugSnag API.

Log messages

BreadcrumbType.LOG breadcrumbs are left when using the breadcrumb log filter.

BreadcrumbType.NAVIGATION breadcrumbs are left for HTTP requests.

endpoint

Sets the URL used to send error reports to BugSnag. By default, endpoint is set to https://notify.bugsnag.com

bugsnag.configure(endpoint='https://example.com/error-reports')

ignore_classes

Sets which exception classes should never be sent to BugSnag. This feature is useful when you have a large number of 404 errors and do not want them all sent to BugSnag.

bugsnag.configure(ignore_classes=["django.http.Http404"])

By default, ignore_classes is set to [].

max_breadcrumbs

Sets the maximum number of breadcrumbs which will be stored. Once the threshold is reached, the oldest breadcrumbs will be deleted.

By default, 25 breadcrumbs are stored; this can be amended up to a maximum of 100.

bugsnag.configure(max_breadcrumbs=40)

notify_release_stages

By default, we will notify BugSnag of exceptions that happen in any release_stage. If you would like to change which release stages notify BugSnag of exceptions you can set notify_release_stages:

bugsnag.configure(notify_release_stages=["production", "development"])

params_filters

Sets the strings to filter out from the params hashes before sending them to BugSnag. Use this if you want to ensure you don’t send sensitive data such as passwords, and credit card numbers to our servers. Any keys which contain these strings will be filtered.

bugsnag.configure(params_filters=["credit_card_number"])

project_root

We mark stacktrace lines as inProject if they come from files inside your project_root:

bugsnag.configure(project_root="/var/www/myproject")

release_stage

If you would like to distinguish between errors that happen in different stages of the application release process (development, production, etc) you can set the release_stage that is reported to BugSnag.

bugsnag.configure(release_stage = "development")

In Django apps this value is automatically set to development if the server running is the Django development server. Otherwise the default is production.

send_code

By default, we send a few lines of source code to BugSnag along with the exception report. If you want to stop this from happening, you can set send_code:

bugsnag.configure(send_code=False)

send_environment

By default, we don’t attach the request environment (if any) to each event. If you want to enable this, you can set send_environment:

bugsnag.configure(send_environment=True)

Individual fields can also be redacted using params_filters.

session_endpoint

Set the endpoint to which tracked sessions reports are sent. This defaults to https://sessions.bugsnag.com, but should be overridden if you are using BugSnag On-premise, to point to your own BugSnag endpoint:

bugsnag.configure(session_endpoint='http://bugsnag.example.com:49000')

traceback_exclude_modules

A list of modules to exclude from tracebacks. This is useful if you are wrapping bugsnag.notify() in with your own library. Normally every traceback would end with that line in your logging library, which would cause bugsnag to group all errors as occurences of a single error, no matter where they came from in your program. You can use this option to exclude your custom logging module from the tracebacks, causing things to be grouped properly. Note this list must contain actual modules of type module, not strings that are module identifiers.

import myapp.custom_logging
bugsnag.configure(traceback_exclude_modules=[myapp.custom_logging])