Configuration

The environment name for this installation. This will also control defaults for things like DEBUG.

SENTRY_ENVIRONMENT=production sentry ...

The technical contact address for this installation. This will be reported to upstream to the Sentry team (as part of the Beacon), and will be the point of contact for critical updates and security notifications.

system.admin-email: "admin@example.com"

The URL prefix in which Sentry is accessible. This will be used both for referencing URLs in the UI, as well as in outbound notifications. This only works for scheme, hostname and port.

system.url-prefix: "https://sentry.example.com"

A secret key used for session signing. If this becomes compromised it’s important to regenerate it as otherwise its much easier to hijack user sessions.

system.secret-key: "a-really-long-secret-value"

To generate a new value, we’ve provided a helper:

sentry config generate-secret-key

Sentry can override logger levels by providing the CLI with the -l/--loglevel flag.

The value of this can be one of the standard Python logging level strings.

sentry --loglevel=WARNING

Sentry can override logger levels with the SENTRY_LOG_LEVEL environment variable.

The value of this can be one of the standard Python logging level strings.

SENTRY_LOG_LEVEL=WARNING sentry ...

You can modify or override the full logging configuration with this setting. Be careful not to remove or override important defaults. You can check the default configuration for reference.

LOGGING['default_level'] = 'WARNING'

If logging in a particular module is not showing up when you expect it to, you should check the log level for that module in src/sentry/conf/server.py in the LOGGING variable.

Describes the Redis clusters available to the Sentry server. These clusters may then be referenced by name by other internal services such as the cache, digests, and TSDB backends, among others.

For example,

redis.clusters:
  default: # cluster name
    hosts: # connection options, passed to `rb.Cluster`
      0:
        host: redis-1.example.com
        port: 6379
      1:
        host: redis-2.example.com
        port: 6379
  other:
    hosts:
      0:
        host: redis-3.example.com
        port: 6379

Should Sentry allow users to create new accounts?

Defaults to False.

This setting only controls public registration. Users can still register new accounts via Single Sign-On and membership invites.

auth.allow-registration: true

Note: This setting is often configured via the UI.

Should Sentry make all data publicly accessible? This should only be used if you’re installing Sentry behind your company’s firewall.

Users will still need to have an account to view any data.

Defaults to False.

SENTRY_PUBLIC = True

If provided, Sentry will set the Access-Control-Allow-Origin header to this value on /api/store/ responses. In addition, the Access-Control-Allow-Headers header will be set to ‘X-Sentry-Auth’. This allows JavaScript clients to submit cross-domain error reports.

You can read more about these headers in the Mozilla developer docs.

Defaults to None (don’t add the Access-Control headers)

SENTRY_ALLOW_ORIGIN = "http://foo.example"

The hostname which the webserver should bind to.

Defaults to localhost.

SENTRY_WEB_HOST = '0.0.0.0'  # bind to all addresses

The port which the webserver should listen on.

Defaults to 9000.

SENTRY_WEB_PORT = 9000

A dictionary of additional configuration options to pass to uwsgi.

Defaults to {}.

SENTRY_WEB_OPTIONS = {
    'workers': 10,
    'buffer-size': 32768,
}

Your GitHub App ID.

The name of your GitHub App.

The secret used to verify GitHub App Webhook event.

Your app's private key.

Your GitHub App's Client ID.

Your GitHub App's Client Secret.

Your Azure DevOps application App ID

Your Azure DevOps application App Secret