All available options for configuring BugSnag with Symfony.
The BugSnag client object has several methods which help you customize the content of error reports, and how the reports are delivered. Most configuration options can be automatically populated by environment variables and/or Symfony configuration within config/packages/bugsnag.yaml
.
You can set the BugSnag API key by setting the BUGSNAG_API_KEY
environment variable, or by setting api_key
within config/packages/bugsnag.yaml
:
bugsnag:
api_key: YOUR-API-KEY-HERE
This setting is the only one which is required in order to use the notifier.
You can find your API key in Project Settings from your BugSnag dashboard.
Unhandled exceptions in your Symfony app will be automatically reported to your BugSnag dashboard. You can toggle auto notifying by setting auto_notify
within config/packages/bugsnag.yaml
:
bugsnag:
auto_notify: true
By default, this is set to true
.
You can set the type of application executing the current code by using setAppType
:
$this->bugsnag->setAppType('Mailer');
You can also modify this within config/packages/bugsnag.yaml
:
bugsnag:
app_type: Mailer
By default this is set to Console
or HTTP
depending on the context.
To track in which versions of your application each exception happens, set the app version:
$this->bugsnag->setAppVersion('1.2.3');
You can also modify this within config/packages/bugsnag.yaml
:
bugsnag:
app_version: 1.2.3
This is not set by default.
If you’d like us to send the errors through to BugSnag when the PHP process shuts down, in order to prevent your app waiting on HTTP requests, this can be set to true
. Setting it to false
will mean the we send an HTTP request straight away for each error.
$this->bugsnag->setBatchSending(true);
You can also modify this within config/packages/bugsnag.yaml
:
bugsnag:
batch_sending: true
By default, this is set to true
.
You can also flush our error buffer by calling the flush
function, causing any queued errors to be sent immediately:
$this->bugsnag->flush(true);
Set a callback attached to the notification pipeline when notifying BugSnag of an error. You can use this to call your own error handling functions or customize the error report.
$this->bugsnag->registerCallback(function ($report) {
// Inspect or modify the error report here
});
To cancel sending an error report, return false
from the function.
Allows you to specify which events should be automatically discarded based on the class name of the exception.
Accepts both strings and regexes, and comparisons are case sensitive.
$this->bugsnag->setDiscardClasses([
\Example\Exception::class,
'/^Example\\.+/',
]);
You can also modify this within config/packages/bugsnag.yaml
:
bugsnag:
discard_classes:
- Example\Exception
- /^Example\\.+/
By default, no classes are discarded
You can change the BugSnag endpoint by setting the BUGSNAG_ENDPOINT
environment variable, or by setting endpoint
within config/packages/bugsnag.yaml
:
bugsnag:
endpoint: https://example.com
By default, this is set to https://notify.bugsnag.com
.
Declare feature flag and experiment usage.
addFeatureFlag
Declare a single feature flag or experiment with variant as an optional second parameter.
$this->bugsnag->addFeatureFlag('Checkout button color', 'Blue')
$this->bugsnag->addFeatureFlag('New checkout flow')
addFeatureFlags
Declare multiple feature flags or experiments.
$this->bugsnag->addFeatureFlags([
new \Bugsnag\FeatureFlag('Checkout button color', 'Blue'),
new \Bugsnag\FeatureFlag('Special offer', 'Free Coffee'),
new \Bugsnag\FeatureFlag('New checkout flow'),
])
If addFeatureFlags
is called again, the new data will be merged with any existing feature flags with the newer variant values taking precedence.
Feature flags can also be added in config/packages/bugsnag.yaml
:
bugsnag:
feature_flags:
- name: Checkout button color
variant: Blue
- name: Special offer
variant: Free coffee
- name: New checkout flow
See the Feature flags & experiments guide for more information.
Deprecated: Use redactedKeys
instead.
Sets the strings to filter out from the metaData
arrays 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 (ignoring case) will be filtered.
$this->bugsnag->setFilters(array_merge(
$this->bugsnag->getFilters(),
['credit_card']
));
You can also modify these within config/packages/bugsnag.yaml
. Note that this will override any defaults.
bugsnag:
filters:
- password
- credit_card
By default, this is set to be
['password', 'cookie', 'authorization', 'php-auth-user', 'php-auth-pw', 'php-auth-digest']
If you would like to set the hostname of your server to something specific for you to identify it by, then you can call this method with your desired hostname.
$this->bugsnag->setHostname('your-hostname');
You can also modify this within config/packages/bugsnag.yaml
:
bugsnag:
hostname: your-hostname
By default this is set to php_uname('n')
.
Sets the maximum number of breadcrumbs which will be stored. Once the threshold is reached, the oldest breadcrumbs will be deleted.
By default, 50 breadcrumbs are stored; this can be amended up to a maximum of 100.
$this->bugsnag->setMaxBreadcrumbs(100);
You can also modify this within config/packages/bugsnag.yaml
:
bugsnag:
max_breadcrumbs: 100
BugSnag will increase the PHP memory limit when your app runs out of memory to ensure events can be delivered. You can control the number of bytes BugSnag will increase the memory limit by with the setMemoryLimitIncrease
method.
$this->bugsnag->setMemoryLimitIncrease(1024 * 1024 * 10); // 10 MiB
To disable this behaviour, pass null
instead.
You can also modify this within config/packages/bugsnag.yaml
:
bugsnag:
memory_limit_increase: 10485760
By default this is set to 5 MiB (1024 * 1024 * 5
)
This option only takes effect when Symfony’s ErrorHandler component is used, which was added in Symfony 4.4. Older versions of Symfony use the Debug component, which does not inform BugSnag of out of memory exceptions.
Here you can set additional metadata to send with every bugsnag notification. By default, we merge your new metadata with anything already existing on the config object. You can pass false
as the 2nd parameter to disable this behaviour.
$this->bugsnag->setMetaData([
'account' => [
'paying' => true,
'name' => 'Acme Co'
]
]);
BugSnag marks stacktrace lines as in-project if they come from files inside your “project root”. This can be set by calling setProjectRoot
on our client.
$this->bugsnag->setProjectRoot('/path/to/your/app/src');
If you wish to use regular expressions, you can call setProjectRootRegex
on the client.
$this->bugsnag->setProjectRootRegex('/^\/path\/to\/your\/app\/src[\\/]?/i');
It also trims this path from the start of any filepath. If you want to change the strip path, see strip path.
You can also modify these within config/packages/bugsnag.yaml
:
bugsnag:
project_root: '/path/to/your/app/src'
project_root_regex: '/^\/path\/to\/your\/app\/src[\\/]?/i'
By default, we’ll set your src
folder as the project root.
If you’d like to set a proxy for us to use, you can set the HTTP_PROXY
or HTTPS_PROXY
variables for Guzzle.
Note that HTTP_PROXY
is only available in cli, and if HTTPS_PROXY
is present, it’ll replace HTTP_PROXY
.
Sets which values should be removed from any metadata before sending them to BugSnag. Use this if you want to ensure you don’t transmit sensitive data such as passwords and credit card numbers.
Any property whose key matches a redacted key will be filtered and replaced with [FILTERED]
.
Accepts both strings and regexes, and string comparisons are case insensitive.
$this->bugsnag->setRedactedKeys([
'access_token', // case-insensitive: "access_token", "ACCESS_TOKEN", "AcCeSs_ToKeN"
'/^cc_/' // prefix match: "cc_number" "cc_cvv" "cc_expiry"
]);
You can also modify this within config/packages/bugsnag.yaml
:
bugsnag:
redacted_keys:
- access_token
- /^cc_/
By default, this is set to be
['password', 'cookie', 'authorization', 'php-auth-user', 'php-auth-pw', 'php-auth-digest']
The default values are set by the filters
option.
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 releaseStage
that is reported to BugSnag.
$this->bugsnag->setReleaseStage('development');
You can also modify this within config/packages/bugsnag.yaml
:
bugsnag:
release_stage: development
By default, we’ll automatically detect the app environment by looking at kernel.environment
, and BugSnag is notified of errors that happen in any releaseStage
.
If you would like to change which release stages notify BugSnag of errors you can call setNotifyReleaseStages
.
$this->bugsnag->setNotifyReleaseStages(['development', 'production']);
You can also modify these within config/packages/bugsnag.yaml
:
bugsnag:
notify_release_stages:
- development
- production
If notify_release_stages
are not set notifications will still be delivered.
BugSnag automatically sends a small snippet of the code that crashed to help you diagnose even faster from within your dashboard. If you don’t want to send this snippet, you can call setSendCode
:
$this->bugsnag->setSendCode(false);
You can also modify this within config/packages/bugsnag.yaml
:
bugsnag:
send_code: false
By default, this is set to true
.
To make stacktraces clearer, BugSnag can trim file paths using the setStripPath
function.
$this->bugsnag->setStripPath('/path/to/your/app');
If you wish to use regular expressions, you can call setStripPathRegex
on the client.
$this->bugsnag->setStripPathRegex('/^\/path\/to\/your\/app[\\/]?/i');
If the project root is set, the strip path will be set automatically too.
You can also modify these within config/packages/bugsnag.yaml
:
bugsnag:
strip_path: '/path/to/your/app'
strip_path_regex: '/^\/path\/to\/your\/app[\\/]?/i'
By default, we’ll set the strip path to one directory above the src
folder.
You enable or disable user information collection by using setUser
:
$this->bugsnag->setUser(false);
You can also modify this within config/packages/bugsnag.yaml
:
bugsnag:
user: false
By default, this is set to true
.