Data Collected for Rack Middleware
See what data is collected by the Sentry Ruby SDK.
Sentry takes data privacy very seriously and has default settings in place that prioritize data safety, especially when it comes to personally identifiable information (PII) data. When you add the Sentry SDK to your application, you allow it to collect data and send it to Sentry during the runtime of your application.
The category types and amount of data collected vary, depending on the integrations you've enabled in the Sentry SDK. Here's a list of data categories the Sentry Ruby SDK collects. You can control automatic collection for many of these categories with data_collection.
By default, the Sentry SDK will include non-sensitive HTTP headers from a Rack request. Sensitive headers such as IP addresses and HTTP_AUTHORIZATION will be filtered out by default.
Use config.data_collection.http_headers.request to control request header collection. Request and response headers can be configured independently with http_headers.request and http_headers.response. Set either option to true to collect non-sensitive values, or false to disable collection.
By default, the Sentry SDK doesn't send cookies.
To collect cookies, set config.data_collection.cookies to true. This is shorthand for mode: :deny_list, which collects values except those matching the built-in sensitive data filters:
config.data_collection.cookies = true
config.data_collection.cookies = true
To customize which cookie values are collected, configure the mode and terms options instead.
By default, the Sentry SDK doesn't send the user's IP address.
To enable sending the user's IP address, set config.data_collection.user_info = true.
The request URL (without query string) of outgoing and incoming HTTP requests is always sent to Sentry. Depending on your application, this could potentially contain PII data.
Use config.data_collection.url_query_params to control the query string of outgoing and incoming HTTP requests. Set it to false to disable collection, or true to collect values except those matching the built-in sensitive data filters. To restrict which values are sent, use :allow_list and terms instead.
Use config.data_collection.http_bodies to control request body collection. For example, to collect incoming and outgoing request bodies:
config.data_collection.http_bodies = [:incoming_request, :outgoing_request]
config.data_collection.http_bodies = [:incoming_request, :outgoing_request]
We try to decode JSON and form data bodies in UTF-8 encoding. Raw byte payloads will not be sent to Sentry.
The Rails integration stores trace propagation headers in serialized Active Job payloads. You can disable this with config.rails.active_job_propagate_traces = false.
When config.data_collection.user_info is enabled, the payload also includes the current user's id, email, and username. Failed-job events include serialized job arguments and, on Rails 7 or later, context set with Rails.error.set_context when config.data_collection.queues is enabled.
When an unhandled exception is sent to Sentry, a snapshot of the source code surrounding the line where the error originates is sent with it.
To control the amount of source context sent to Sentry, set config.data_collection.frame_context_lines.
By default, Sentry for Ruby does not include local variables in the frames of captured exceptions, mainly due to performance overhead reasons.
You can start sending local variables to Sentry by setting config.data_collection.stack_frame_variables = true.
The graphql configuration controls whether the GraphQL integration collects documents and variables. You can disable either category independently:
config.data_collection.graphql.document = false
config.data_collection.graphql.variables = false
config.data_collection.graphql.document = false
config.data_collection.graphql.variables = false
SQL queries are sent to Sentry in a parameterized form. To control whether associated query data, such as bound parameter values and Redis command arguments, is collected, set config.data_collection.database_query_data = false.
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").