---
title: "Options"
description: "Learn more about how the SDK can be configured via options. These are being passed to the init function and therefore set when the SDK is first initialized."
url: https://docs.sentry.io/platforms/ruby/configuration/options/
---

# Options | Sentry for Ruby

Options are passed as attributes to the `config` object within the `init` block:

```ruby
Sentry.init do |config|
  config.dsn = '___PUBLIC_DSN___'
  config.max_breadcrumbs = 5
  config.debug = true

  # Add data like request headers and IP for users, if applicable;
  # see https://docs.sentry.io/platforms/ruby/data-management/data-collected/ for more info
  config.send_default_pii = true

  # enable tracing
  # we recommend adjusting this value in production
  config.traces_sample_rate = 1.0
end
```

## [Available Options](https://docs.sentry.io/platforms/ruby/configuration/options.md#available-options)



## [Core Options](https://docs.sentry.io/platforms/ruby/configuration/options.md#core-options)

Options that can be read from an environment variable (`SENTRY_DSN`, `SENTRY_ENVIRONMENT`, `SENTRY_RELEASE`) will be read automatically.

### [dsn](https://docs.sentry.io/platforms/ruby/configuration/options.md#dsn)

| Type | `String` |
| ---- | -------- |

The DSN tells the SDK where to send events. If this value isn't provided, the SDK will try to read it from the `SENTRY_DSN` environment variable. If that variable doesn't exist, the SDK won't send any events.

Learn more about [DSN utilization](https://docs.sentry.io/product/sentry-basics/dsn-explainer.md#dsn-utilization).

### [debug](https://docs.sentry.io/platforms/ruby/configuration/options.md#debug)

| Type    | `Boolean` |
| ------- | --------- |
| Default | `false`   |

This turns debug mode on or off. When enabled, SDK errors will be logged with backtrace. If you want more output, use `config.sdk_logger.level`. `debug` only works for attaching backtraces to the messages.

### [sdk\_logger](https://docs.sentry.io/platforms/ruby/configuration/options.md#sdk_logger)

| Type | `Sentry::Logger` |
| ---- | ---------------- |

The logger used by Sentry. The default for Rails is `Rails.logger`, otherwise it's `Sentry::Logger`. Make sure to change the logger level if you need debug output. **We don't recommend doing this in production unless absolutely necessary.**

```ruby
config.sdk_logger = Sentry::Logger.new(STDOUT)
config.sdk_logger.level = ::Logger::DEBUG # defaults to INFO
```

### [release](https://docs.sentry.io/platforms/ruby/configuration/options.md#release)

| Type | `String` |
| ---- | -------- |

Lets you track your application version in Sentry.

We intelligently guess the release in the following order of preference:

* The `SENTRY_RELEASE` environment variable
* Kamal’s deploy metadata via the `KAMAL_VERSION` environment variable
* Commit SHA of the last commit (git)
* Reading from the `REVISION` file in the app root (used by Capistrano)
* Heroku’s dyno metadata via the `HEROKU_SLUG_COMMIT` environment variable (must have been enabled via Heroku Labs)

```ruby
Sentry.init do |config|
  #...
  config.release = 'my-project-name@2.3.12'
end
```

We'll automatically attempt to detect the release in certain environments, such as Kamal, Heroku, and Capistrano.

### [sample\_rate](https://docs.sentry.io/platforms/ruby/configuration/options.md#sample_rate)

| Type    | `Float` |
| ------- | ------- |
| Default | `1.0`   |

Configures the sample rate for error events, in the range of `0.0` to `1.0`. The default is `1.0`, which means that 100% of error events will be sent. If set to `0.1`, only 10% of error events will be sent.

```ruby
# send 50% of events
config.sample_rate = 0.5
```

### [send\_client\_reports](https://docs.sentry.io/platforms/ruby/configuration/options.md#send_client_reports)

| Type    | `Boolean` |
| ------- | --------- |
| Default | `true`    |

This lets you attach diagnostic client reports about dropped events to an existing envelope max once every 30s. If you don't want to send this data, opt-out by setting:

```ruby
config.send_client_reports = false
```

### [send\_default\_pii](https://docs.sentry.io/platforms/ruby/configuration/options.md#send_default_pii)

| Type    | `Boolean` |
| ------- | --------- |
| Default | `false`   |

If this flag is enabled, [certain personally identifiable information (PII)](https://docs.sentry.io/platforms/ruby/data-management/data-collected.md) is added to Sentry events.

If you enable this option, be sure to manually remove what you don't want to send using our features for managing [*Sensitive Data*](https://docs.sentry.io/platforms/ruby/data-management/sensitive-data.md).

### [send\_modules](https://docs.sentry.io/platforms/ruby/configuration/options.md#send_modules)

| Type    | `Boolean` |
| ------- | --------- |
| Default | `true`    |

A boolean to decide whether to send module (dependency) information to Sentry.

```ruby
# if you don't want to send all the dependency info
config.send_modules = false
```

### [include\_local\_variables](https://docs.sentry.io/platforms/ruby/configuration/options.md#include_local_variables)

| Type    | `Boolean` |
| ------- | --------- |
| Default | `false`   |

Whether to capture local variables from the raised exceptions frame.

### [auto\_session\_tracking](https://docs.sentry.io/platforms/ruby/configuration/options.md#auto_session_tracking)

| Type    | `Boolean` |
| ------- | --------- |
| Default | `true`    |

Track sessions in request/response cycles automatically.

### [max\_breadcrumbs](https://docs.sentry.io/platforms/ruby/configuration/options.md#max_breadcrumbs)

| Type    | `Integer` |
| ------- | --------- |
| Default | `100`     |

The maximum number of breadcrumbs the SDK could hold.

```ruby
config.max_breadcrumbs = 30
```

### [breadcrumbs\_logger](https://docs.sentry.io/platforms/ruby/configuration/options.md#breadcrumbs_logger)

| Type | `Array` |
| ---- | ------- |

Sentry supports different breadcrumbs loggers in the Ruby SDK:

* `:sentry_logger` - A general breadcrumbs logger for all Ruby applications.
* `:http_logger` - Captures requests made with the standard `net/http` library.
* `:redis_logger` - Captures breadcrumbs from redis operations.
* `:active_support_logger` - Built on top of [ActiveSupport instrumentation](https://guides.rubyonrails.org/active_support_instrumentation.html) and provides many Rails-specific information.

And you can enable them with the `breadcrumbs_logger` option:

```ruby
config.breadcrumbs_logger = [:active_support_logger]
config.breadcrumbs_logger = [:active_support_logger, :http_logger]
```

### [exclude\_loggers](https://docs.sentry.io/platforms/ruby/configuration/options.md#exclude_loggers)

| Type    | `Array<String>` |
| ------- | --------------- |
| Default | `[]`            |

Logger names to exclude from breadcrumbs.

### [context\_lines](https://docs.sentry.io/platforms/ruby/configuration/options.md#context_lines)

| Type    | `Integer` |
| ------- | --------- |
| Default | `3`       |

How many lines to display before/after the line where issue occurs.

### [linecache](https://docs.sentry.io/platforms/ruby/configuration/options.md#linecache)

| Type | `Sentry::LineCache` |
| ---- | ------------------- |

You may provide your own `LineCache` for matching paths with source files to populate `context_lines`. This may be useful if you need to get source code from places other than the disk.

### [environment](https://docs.sentry.io/platforms/ruby/configuration/options.md#environment)

| Type    | `String`      |
| ------- | ------------- |
| Default | `development` |

Sets the environment. This string is freeform and not set by default. A release can be associated with more than one environment so that you can separate them in the UI (think `staging` vs `prod` or similar).

Sentry automatically sets the current environment from the environment variables: `SENTRY_CURRENT_ENV`, `SENTRY_ENVIRONMENT`, `RAILS_ENV`, `RACK_ENV` in that order and defaults to `development`.

### [enabled\_environments](https://docs.sentry.io/platforms/ruby/configuration/options.md#enabled_environments)

| Type    | `Array \| nil` |
| ------- | -------------- |
| Default | `nil`          |

By default, events will be sent to Sentry in all environments. If you don't want to send events in a specific environment, you can unset the `SENTRY_DSN` variable in that environment.

You can also set up Sentry to only run in certain environments by configuring the `enabled_environments` list. For example, to only run Sentry in production:

```ruby
config.enabled_environments = %w[production]
```

### [excluded\_exceptions](https://docs.sentry.io/platforms/ruby/configuration/options.md#excluded_exceptions)

| Type    | `Array`                                 |
| ------- | --------------------------------------- |
| Default | `Sentry::Configuration::IGNORE_DEFAULT` |

You can use this option to stop getting notifications about certain exceptions. In the example below, the exceptions Rails uses to generate 404 responses will be suppressed.

```ruby
config.excluded_exceptions += ['ActionController::RoutingError', 'ActiveRecord::RecordNotFound']
```

You can find the list of exceptions that are excluded by default in `Sentry::Configuration::IGNORE_DEFAULT`. It is suggested that you append to these defaults rather than overwrite them with `=`.

### [inspect\_exception\_causes\_for\_exclusion](https://docs.sentry.io/platforms/ruby/configuration/options.md#inspect_exception_causes_for_exclusion)

| Type    | `Boolean` |
| ------- | --------- |
| Default | `true`    |

Inspect an incoming exception's causes when determining whether or not that exception should be excluded. This option works together with `excluded_exceptions`.

```ruby
config.inspect_exception_causes_for_exclusion = true
```

### [enabled\_patches](https://docs.sentry.io/platforms/ruby/configuration/options.md#enabled_patches)

| Type    | `Array`                  |
| ------- | ------------------------ |
| Default | `[:http, :redis, :puma]` |

Some of our integrations work via patches that need to be enabled. Use this option to control which patches are loaded when the SDK is initialized.

The list of all available patches is: `[:http, :redis, :puma, :graphql, :faraday]`.

```ruby
# enable :faraday patch
config.enabled_patches << :faraday

# disable :puma patch
config.enabled_patches.delete(:puma)
```

### [project\_root](https://docs.sentry.io/platforms/ruby/configuration/options.md#project_root)

| Type    | `String`  |
| ------- | --------- |
| Default | `Dir.pwd` |

Project directory root for `in_app` detection. Set to `Rails.root` for Rails applications.

### [app\_dirs\_pattern](https://docs.sentry.io/platforms/ruby/configuration/options.md#app_dirs_pattern)

| Type    | `Regexp`                                     |
| ------- | -------------------------------------------- |
| Default | `/(bin\|exe\|app\|config\|lib\|test\|spec)/` |

Directories to be recognized as `in_app` in backtrace frames.

### [strip\_backtrace\_load\_path](https://docs.sentry.io/platforms/ruby/configuration/options.md#strip_backtrace_load_path)

| Type    | `Boolean` |
| ------- | --------- |
| Default | `true`    |

Whether to strip the load path while constructing the backtrace frame filename.

### [skip\_rake\_integration](https://docs.sentry.io/platforms/ruby/configuration/options.md#skip_rake_integration)

| Type    | `Boolean` |
| ------- | --------- |
| Default | `false`   |

Determine whether to ignore exceptions caused by rake integrations.

### [rack\_env\_whitelist](https://docs.sentry.io/platforms/ruby/configuration/options.md#rack_env_whitelist)

| Type    | `Array<String>`                                 |
| ------- | ----------------------------------------------- |
| Default | `["REMOTE_ADDR", "SERVER_NAME", "SERVER_PORT"]` |

Array of rack env parameters to be included in the event sent to sentry.

### [server\_name](https://docs.sentry.io/platforms/ruby/configuration/options.md#server_name)

| Type | `String` |
| ---- | -------- |

This option can be used to supply a server name sent in the event payload.

If running on Heroku, it is set to `ENV["DYNO"]` otherwise set to `Socket.gethostname`.

### [trusted\_proxies](https://docs.sentry.io/platforms/ruby/configuration/options.md#trusted_proxies)

| Type | `Array` |
| ---- | ------- |

These trusted proxies will be skipped when the SDK computes the user's ip address and `sentry-rails` will automatically inject the value of `Rails.application.config.action_dispatch.trusted_proxies` to this option.

```ruby
config.trusted_proxies = ["2.2.2.2"]
```

## [Tracing Options](https://docs.sentry.io/platforms/ruby/configuration/options.md#tracing-options)

### [traces\_sample\_rate](https://docs.sentry.io/platforms/ruby/configuration/options.md#traces_sample_rate)

| Type    | `Float` |
| ------- | ------- |
| Default | `nil`   |

A number between `0` and `1` that determines the percentage of total transaction that will be sent to Sentry (with 0 representing 0% and 1, 100%). This will apply equally to all transactions created in the app. Either this or `traces_sampler` must be defined to enable tracing.

If `traces_sample_rate` is set to 0, no new traces will be created. However, if you have another service (for example a JS frontend) that makes requests to your service and has trace information, those traces will be continued and transactions will be sent to Sentry.

To disable all tracing, you'll need to set `traces_sample_rate = nil`. Once this is done, no new traces will be started and no incoming traces will be continued.

```ruby
Sentry.init do |config|
  # ...
  config.traces_sample_rate = 0.2
end
```

### [traces\_sampler](https://docs.sentry.io/platforms/ruby/configuration/options.md#traces_sampler)

| Type | `lambda \| proc` |
| ---- | ---------------- |

A lambda or proc that's responsible for determining the chance that a given transaction has of being sent to Sentry (from 0-100%). It will automatically be passed information about the transaction and the context in which it's being created, and must return a number between `0` (0% chance of being sent) and `1` (100% chance of being sent).

It can also be used for filtering transactions, by returning 0 for those that are of no interest. Either this or `traces_sample_rate` must be defined to enable tracing.

```ruby
Sentry.init do |config|
  #...
  config.traces_sampler = lambda do |sampling_context|
    # if this is the continuation of a trace, just use that decision (rate controlled by the caller)
    unless sampling_context[:parent_sampled].nil?
      next sampling_context[:parent_sampled]
    end

    # the sampling context also has the full rack environment if you want to check the path directly
    rack_env = sampling_context[:env]
    return 0.0 if rack_env && rack_env['PATH_INFO'] =~ /health_check/

    # transaction_context is the transaction object in hash form
    # keep in mind that sampling happens right after the transaction is initialized
    # for example, at the beginning of the request
    transaction_context = sampling_context[:transaction_context]

    # transaction_context helps you sample transactions with more sophistication
    # for example, you can provide different sample rates based on the operation or name
    op = transaction_context[:op]
    transaction_name = transaction_context[:name]

    case op
    when /http/
      # for Rails applications, transaction_name would be the request's path (env["PATH_INFO"]) instead of "Controller#action"
      case transaction_name
      when /health_check/
        0.0
      when /payment/
        0.5
      when /api/
        0.2
      else
        0.1
      end
    when /queue/
      0.01 # you may want to set a lower rate for background jobs if the number is large
    else
      0.0 # ignore all other transactions
    end
  end
end
```

### [enable\_backpressure\_handling](https://docs.sentry.io/platforms/ruby/configuration/options.md#enable_backpressure_handling)

| Type    | `Boolean` |
| ------- | --------- |
| Default | `false`   |

A boolean that controls whether a new monitor thread will be spawned to perform health checks on the SDK. If the system is unhealthy, the SDK will keep halving the `traces_sample_rate` set by you in 10 second intervals until recovery. This downsampling helps ensure that the system stays stable and reduces SDK overhead under high load.

### [trace\_propagation\_targets](https://docs.sentry.io/platforms/ruby/configuration/options.md#trace_propagation_targets)

| Type | `Array<String, Regexp>` |
| ---- | ----------------------- |

An optional property that controls which downstream services receive tracing data, in the form of a `sentry-trace` and a `baggage` header attached to any outgoing HTTP requests.

The option may contain an array of strings or regex against which the URLs of outgoing requests are matched. If one of the entries in the list matches the URL of an outgoing request, trace headers will be attached to that request. String entries don't have to be full matches, (meaning the URL of a request is matched when it *contains* a string provided through the option).

By default, trace headers are attached to every outgoing request from the instrumented client.

### [propagate\_traces](https://docs.sentry.io/platforms/ruby/configuration/options.md#propagate_traces)

| Type    | `Boolean` |
| ------- | --------- |
| Default | `true`    |

By default, Sentry injects `sentry-trace` and `baggage` headers to outgoing requests made with `Net::HTTP` to connect traces between services. You can disable this behavior with:

```ruby
config.propagate_traces = false
```

### [trace\_ignore\_status\_codes](https://docs.sentry.io/platforms/ruby/configuration/options.md#trace_ignore_status_codes)

| Type    | `Array<Integer \| Range>`              |
| ------- | -------------------------------------- |
| Default | `[(301..303), (305..399), (401..404)]` |

An optional property that disables tracing for HTTP requests with certain status codes.

Requests are not traced if the status code is contained in the provided list.

```ruby
config.trace_ignore_status_codes = [404, (502..511)]
```

### [instrumenter](https://docs.sentry.io/platforms/ruby/configuration/options.md#instrumenter)

| Type    | `Symbol`  |
| ------- | --------- |
| Default | `:sentry` |

The instrumenter to use, `:sentry` or `:otel` for [use with OpenTelemetry](https://docs.sentry.io/platforms/ruby/tracing/instrumentation/opentelemetry.md).

## [Hooks](https://docs.sentry.io/platforms/ruby/configuration/options.md#hooks)

The below options can be used to hook the SDK in various ways and customize how events are being reported.

### [before\_send](https://docs.sentry.io/platforms/ruby/configuration/options.md#before_send)

| Type | `lambda \| proc` |
| ---- | ---------------- |

Provides a lambda or proc that's called with a message or error event object, and can return a modified event object, or `nil` to skip reporting the event. This can be used, for instance, for manual PII stripping before sending.

By the time `before_send` is executed, all scope data has already been applied to the event. Further modification of the scope won't have any effect.

```ruby
Sentry.init do |config|
  # ...
  config.before_send = lambda do |event, hint|
    # skip ZeroDivisionError exceptions
    # note: hint[:exception] would be a String if you use async callback
    if hint[:exception].is_a?(ZeroDivisionError)
      nil
    else
      event
    end
  end
end
```

### [before\_send\_transaction](https://docs.sentry.io/platforms/ruby/configuration/options.md#before_send_transaction)

| Type | `lambda \| proc` |
| ---- | ---------------- |

Provides a lambda or proc that's called with a transaction event object, and can return a modified transaction event object, or `nil` to skip reporting the event. One way this might be used is for manual PII stripping before sending.

```ruby
Sentry.init do |config|
  # ...
  config.before_send_transaction = lambda do |event, _hint|
    # skip unimportant transactions
    if event.transaction == "/unimportant/healthcheck/route"
      # don't send the event to Sentry
      nil
    else
      # filter out SQL queries from spans with sensitive data
      event.spans.each do |span|
        span[:description] = '<FILTERED>' if span[:op].start_with?('db')
      end

      event
    end
  end
end
```

### [before\_send\_log](https://docs.sentry.io/platforms/ruby/configuration/options.md#before_send_log)

| Type | `lambda \| proc` |
| ---- | ---------------- |

Provides a lambda or proc that's called with an SDK-specific log object, and can return a modified log object, or `nil` to skip reporting the log. This can be used to filter logs before they are sent to Sentry.

```ruby
Sentry.init do |config|
  config.dsn = "___PUBLIC_DSN___"
  config.enable_logs = true

  config.before_send_log = lambda do |log|
    # Skip info logs
    return if log.level == :info

    log
  end
end
```

### [std\_lib\_logger\_filter](https://docs.sentry.io/platforms/ruby/configuration/options.md#std_lib_logger_filter)

| Type | `lambda \| proc` |
| ---- | ---------------- |

Provides a lambda or proc that's called to filter log messages from Ruby's standard library logger before they are sent to Sentry. This option is only used when the `:logger` patch is enabled via `config.enabled_patches`.

The callback receives three arguments: `logger` (the logger instance), `message` (the log message string), and `severity` (the log severity level). Return `true` to send the log to Sentry, or `false` to skip it.

```ruby
Sentry.init do |config|
  config.dsn = "___PUBLIC_DSN___"
  config.enable_logs = true
  config.enabled_patches << :logger

  # Only send ERROR and FATAL logs to Sentry
  config.std_lib_logger_filter = proc do |logger, message, severity|
    [:error, :fatal].include?(severity)
  end
end
```

### [before\_send\_check\_in](https://docs.sentry.io/platforms/ruby/configuration/options.md#before_send_check_in)

| Type | `lambda \| proc` |
| ---- | ---------------- |

Provides a lambda or proc that's called with a check-in event object, and can return a modified check-in event object, or `nil` to skip reporting the event.

```ruby
Sentry.init do |config|
  # ...
  config.before_send_check_in = lambda do |event, _hint|
    if event.monitor_slug == "unimportant_job"
      nil
    else
      event
    end
  end
end
```

### [backtrace\_cleanup\_callback](https://docs.sentry.io/platforms/ruby/configuration/options.md#backtrace_cleanup_callback)

| Type | `lambda` |
| ---- | -------- |

If you want to clean up the backtrace of an exception before it's sent to Sentry, you can specify a callback with `backtrace_cleanup_callback`, for example:

```ruby
config.backtrace_cleanup_callback = lambda do |backtrace|
  Rails.backtrace_cleaner.clean(backtrace)
end
```

```ruby
Sentry.init do |config|
  # ...
  config.before_send_transaction = lambda do |event, _hint|
    # skip unimportant transactions
    if event.transaction == "/unimportant/healthcheck/route"
      # don't send the event to Sentry
      nil
    else
      # filter out SQL queries from spans with sensitive data
      event.spans.each do |span|
        span[:description] = '<FILTERED>' if span[:op].start_with?('db')
      end

      event
    end
  end
end
```

### [before\_breadcrumb](https://docs.sentry.io/platforms/ruby/configuration/options.md#before_breadcrumb)

| Type | `lambda \| proc` |
| ---- | ---------------- |

This function is called with a breadcrumb object before the breadcrumb is added to the scope. When `nil` is returned from the function, the breadcrumb is dropped. To pass the breadcrumb through, return the first argument, which contains the breadcrumb object. The callback typically gets a second argument (called a "hint") which contains the original object from which the breadcrumb was created to further customize what the breadcrumb should look like.

```ruby
Sentry.init do |config|
  # ...

  # this will be called before every breadcrumb is added to the breadcrumb buffer
  # you can use it to
  # - remove the data you don't want to send
  # - add additional info to the data
  config.before_breadcrumb = lambda do |breadcrumb, hint|
    breadcrumb.message = "foo"
    breadcrumb
  end
end
```

## [Transport Options](https://docs.sentry.io/platforms/ruby/configuration/options.md#transport-options)

### [background\_worker\_threads](https://docs.sentry.io/platforms/ruby/configuration/options.md#background_worker_threads)

| Type | `Integer` |
| ---- | --------- |

Sentry will send events in a non-blocking way with its own background worker. By default, the worker holds a thread pool that has [the number of available processors](https://ruby-concurrency.github.io/concurrent-ruby/master/Concurrent.html#available_processor_count-class_method) threads. But you can override it as follows:

```ruby
config.background_worker_threads = 5
```

Or if you want to send events synchronously, set the value to 0:

```ruby
config.background_worker_threads = 0
```

### [background\_worker\_max\_queue](https://docs.sentry.io/platforms/ruby/configuration/options.md#background_worker_max_queue)

| Type    | `Integer` |
| ------- | --------- |
| Default | `30`      |

The maximum queue size for the background worker. Jobs will be rejected above this limit.

### [transport\_class](https://docs.sentry.io/platforms/ruby/configuration/options.md#transport_class)

| Type    | `class`                 |
| ------- | ----------------------- |
| Default | `Sentry::HTTPTransport` |

By default, the SDK uses the `Sentry::HTTPTransport` class for sending events to Sentry, which should work for the majority of users. But if you want to use your own Transport class, you can change it with this option:

```ruby
config.transport.transport_class = MyTransportClass
```

It would generally be advisable to derive your custom transport class from `Sentry::HTTPTransport` and just override the necessary logic.

### [proxy](https://docs.sentry.io/platforms/ruby/configuration/options.md#proxy)

| Type | `String \| URI \| Hash` |
| ---- | ----------------------- |

Setup a proxy to use to connect to Sentry. This option is respected by the default `Sentry::HTTPTransport` class. You can set `config.transport.proxy` with as a `String` containing a proxy URI, or a `URI` object, or a `Hash` containing `uri`, `user` and `password` keys.

```ruby
Sentry.init do |config|
  # ...

  # Provide proxy config as a String
  config.transport.proxy = "http://user:password@proxyhost.net:8080"

  # Or a URI
  config.transport.proxy = URI("http://user:password@proxyhost.net:8080")

  # Or a Hash
  config.transport.proxy = {
    uri: "http://proxyhost.net:8080",
    user: "user",
    password: "password"
  }
end
```

### [spotlight](https://docs.sentry.io/platforms/ruby/configuration/options.md#spotlight)

| Type    | `Boolean \| String` |
| ------- | ------------------- |
| Default | `false`             |

Whether to also capture events and traces into [Spotlight](https://spotlightjs.com/setup/other/).

If you set this to true, Sentry will send events and traces to the local Sidecar proxy at `http://localhost:8969/stream`.

If you want to use a different Sidecar proxy address, set this to String with the proxy URL.

## [Cron Options](https://docs.sentry.io/platforms/ruby/configuration/options.md#cron-options)

### [default\_checkin\_margin](https://docs.sentry.io/platforms/ruby/configuration/options.md#default_checkin_margin)

| Type    | `Integer` |
| ------- | --------- |
| Default | `nil`     |

How long (in minutes) after the expected checkin time we will wait until we consider the checkin to have been missed.

```ruby
config.cron.default_checkin_margin = 5
```

### [default\_max\_runtime](https://docs.sentry.io/platforms/ruby/configuration/options.md#default_max_runtime)

| Type    | `Integer` |
| ------- | --------- |
| Default | `nil`     |

How long (in minutes) is the checkin allowed to be `in_progress` before it is considered failed.

```ruby
config.cron.default_max_runtime = 30
```

### [default\_timezone](https://docs.sentry.io/platforms/ruby/configuration/options.md#default_timezone)

| Type    | `String` |
| ------- | -------- |
| Default | `nil`    |

Database style timezone string for checkins.

```ruby
config.cron.default_timezone = "America/New_York"
```

## [Profiler Options](https://docs.sentry.io/platforms/ruby/configuration/options.md#profiler-options)

### [profiles\_sample\_rate](https://docs.sentry.io/platforms/ruby/configuration/options.md#profiles_sample_rate)

| Type    | `Float` |
| ------- | ------- |
| Default | `nil`   |

A number between `0` and `1`, controlling the percentage chance a given sampled transaction will be profiled. (`0` represents 0% while `1` represents 100%.) Applies equally to all profiles created in the app. This is relative to the tracing sample rate - e.g. `0.5` means 50% of sampled transactions will be profiled.

### [profiles\_sample\_interval](https://docs.sentry.io/platforms/ruby/configuration/options.md#profiles_sample_interval)

| Type    | `Float`     |
| ------- | ----------- |
| Default | `1e6 / 101` |

Interval in microseconds at which the profiler will collect samples.

The default is 101 Hz. Note that the 101 is intentional to avoid **lockstep sampling**.

### [profiler\_class](https://docs.sentry.io/platforms/ruby/configuration/options.md#profiler_class)

| Type    | `Class`            |
| ------- | ------------------ |
| Default | `Sentry::Profiler` |

The profiler to use for collecting profiles.

Set to `Sentry::Vernier::Profiler` when using `vernier` and `Sentry::Profiler` when using `stackprof`.

See [the Profiling documentation](https://docs.sentry.io/platforms/ruby/profiling.md) for setup instructions.