Data Collected
See what data is collected by the Sentry 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 and build time of your application.
The category types and amount of data collected vary, depending on the integrations you've enabled in the Sentry SDK. This page lists data categories that the Sentry JavaScript SDK collects.
By default, the Sentry SDK sends HTTP request and response headers.
Use the dataCollection.httpHeaders option to control this. For example, set dataCollection: { httpHeaders: false } to disable it, or use { allow: [...] } or { deny: [...] } to restrict which header values are sent. Values whose keys match Sentry's built-in sensitive denylist (such as auth, token, or password) are automatically scrubbed, while the keys are kept.
By default, the Sentry SDK doesn't send cookies. When using dataCollection, however, cookies are collected with sensitive values (like token or key) scrubbed. Opt out by setting dataCollection: { cookies: false }.
To collect cookies when not using dataCollection, set the deprecated sendDefaultPii: true in Sentry.init(). To disable cookie collection when using dataCollection, set dataCollection: { cookies: false }. You can also restrict which cookie values are sent using { allow: [...] } or { deny: [...] }.
When using dataCollection, the SDK automatically populates user identity fields (user.id, user.email, user.username) from instrumentation. To disable this, set dataCollection: { userInfo: false }.
Without dataCollection (and with sendDefaultPii unset or false), user identity fields are not sent automatically. Some integrations (e.g. User Feedback) may still send data like the user ID, username, and email address when explicitly configured.
When using dataCollection, the SDK sends the user's IP address by default. To disable it, set dataCollection: { userInfo: false }.
Without dataCollection (and with sendDefaultPii unset or false), the user's IP address is not sent. In some integrations such as handleRequest in Astro, the user's IP address can also be sent by enabling trackClientIp.
If sending the IP address is enabled we will try to infer the IP address or use the IP address provided by ip_address in Sentry.setUser(). If you set ip_address: null, the IP address won't be inferred.
Even when this is disabled, IP addresses can still reach Sentry through collected HTTP headers, cookies, or query parameters (for example, the X-Forwarded-For header). If you use dataCollection, add these terms to the partially-matched deny lists for those categories so their values are filtered:
Sentry.init({
dsn: "___PUBLIC_DSN___",
dataCollection: {
httpHeaders: { deny: ["forwarded", "-ip", "remote-", "via", "-user"] },
cookies: { deny: ["forwarded", "-ip", "remote-", "via", "-user"] },
queryParams: { deny: ["forwarded", "-ip", "remote-", "via", "-user"] },
},
});
Sentry.init({
dsn: "___PUBLIC_DSN___",
dataCollection: {
httpHeaders: { deny: ["forwarded", "-ip", "remote-", "via", "-user"] },
cookies: { deny: ["forwarded", "-ip", "remote-", "via", "-user"] },
queryParams: { deny: ["forwarded", "-ip", "remote-", "via", "-user"] },
},
});
The full request URL of outgoing and incoming HTTP requests is always sent to Sentry. Depending on your application, this could contain PII data. For example, a URL like /users/1234/details, where 1234 is a user id (which may be considered PII).
By default, the full request query string of outgoing and incoming HTTP requests is sent to Sentry. Depending on your application, this could contain PII data. For example, a query string like ?user_id=1234, where 1234 is a user id (which may be considered PII).
Use the dataCollection.queryParams option to control this. Set it to false to disable collection entirely, or use { allow: [...] } / { deny: [...] } to filter which values are sent. When dataCollection is used, values whose keys match the built-in sensitive denylist (terms like auth, token, password, and secret) are scrubbed automatically.
Sentry also has some additional server-side data scrubbing in place to remove sensitive data from the query string.
When using dataCollection, incoming and outgoing request bodies are collected by default. To disable body collection, set dataCollection: { httpBodies: [] }. You can also collect only specific body types by providing a subset: "incomingRequest", "outgoingRequest", "incomingResponse", and "outgoingResponse".
Sentry.init({
dsn: "___PUBLIC_DSN___",
dataCollection: {
httpBodies: ["incomingRequest", "outgoingRequest"],
},
});
Sentry.init({
dsn: "___PUBLIC_DSN___",
dataCollection: {
httpBodies: ["incomingRequest", "outgoingRequest"],
},
});
Without dataCollection (and with sendDefaultPii unset or false), Sentry only sends the body size inferred from the content-length header, not the body content itself.
When using dataCollection, incoming and outgoing response bodies are collected by default. To disable response body collection, set dataCollection: { httpBodies: [] } (which disables all body types), or provide a subset that excludes the response types.
Without dataCollection (and with sendDefaultPii unset or false), Sentry only sends the response body size based on the content-length header, not the content itself.
By default, SDKs set up by the Sentry CLI Wizard (@sentry/wizard) will enable uploading source maps to Sentry.
To disable source map upload, see the Source Maps documentation.
The Sentry SDK does not send local variables in the error stack trace in client-side JavaScript SDKs.
By default, the Sentry SDK sends information about the device and runtime to Sentry.
In browser environments, this information is obtained by the User Agent string. The User Agent string contains information about the browser, operating system, and device type.
In server-side environments, the Sentry SDK uses the os module to get information about the operating system and architecture.
By default, our Session Replay SDK masks all text content, images, web views, and user input. This helps ensure that no sensitive data is exposed. You can find more details in the Session Replay documentation.
Session Replay also captures basic information about all outgoing fetch and XHR requests in your application. This includes the URL, request and response body size, method, and status code. If networkDetailAllowUrls are defined, the request and response body will be sent to Sentry as well. This can include PII data if the request or response body contains PII information.
Console messages are also captured by default in Session Replay. To scrub console messages, you can use the beforeAddRecordingEvent option to filter console messages before they are sent to Sentry.
By default, the Sentry SDK sends JS console logs to Sentry as breadcrumbs which may contain PII data.
To disable sending console messages, set console: false in your Sentry.breadcrumbsIntegration config, see the Breadcrumbs documentation.
By default, the Sentry SDK sends the referrer URL to Sentry. This is the URL of the page that linked to the current page.
When using AI integrations, metadata like model ID and used tokens is sent to Sentry.
The content of generative AI inputs (such as prompts and tool arguments) and outputs (such as completions) might carry personal data. Whether it's recorded depends on your configuration: it's not recorded by default with sendDefaultPii, but when you use dataCollection, the genAI category records both inputs and outputs unless you opt out. Metadata like model ID and token counts is always collected.
Use the dataCollection.genAI option to control this. For example, opt out of recording AI message content while keeping the metadata:
Sentry.init({
dsn: "___PUBLIC_DSN___",
dataCollection: {
genAI: {
inputs: false,
outputs: false,
},
},
});
Sentry.init({
dsn: "___PUBLIC_DSN___",
dataCollection: {
genAI: {
inputs: false,
outputs: 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").