All available options for configuring your integration with BugSnag.
Your BugSnag API key (required)
You can find your API key in Project Settings from your BugSnag dashboard.
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.
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.
By default, requests are sent asynchronously to BugSnag. If you would
like to block until the request is done, you can set
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
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
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,
UrllibDelivery is used.
from bugsnag.delivery import UrllibDelivery bugsnag.configure(delivery=UrllibDelivery())
To use a custom
delivery, implement the
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())
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:
The following automatic breadcrumb types can be enabled:
BreadcrumbType.ERROR breadcrumbs are left when an error event is sent to the BugSnag API.
BreadcrumbType.LOG breadcrumbs are left when using the breadcrumb log filter.
Sets the URL used to send error reports to BugSnag. By default,
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.
ignore_classes is set to
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.
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
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.
We mark stacktrace lines as
inProject if they come from files inside your
If you would like to distinguish between errors that happen in different stages
of the application release process (development, production, etc) you can set
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
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
By default, we don’t attach the request environment (if any) to each event. If you want to enable this, you can set
Individual fields can also be redacted using
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:
A list of modules to exclude from tracebacks. This is useful if you are
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])