Data Collected for Astro
See what data is collected by the Sentry JavaScript 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 SDK sends HTTP request and response headers. It always keeps the header names and replaces the values of sensitive headers (names that match terms such as auth, token, or password) with [Filtered].
Which headers are sent depends on the environment:
- In the browser, the SDK sends the request headers it gathers itself (
RefererandUser-Agent). ThehttpClientintegration, which is not enabled by default, adds the request and response headers of failed requests. - On the server, the headers of incoming requests are attached to error events and server spans. On some runtimes (such as Bun and Deno), the response headers of incoming requests are attached to server spans as well.
- The headers of outgoing requests are not collected by default.
Use the dataCollection.httpHeaders option to control header collection. Set dataCollection: { httpHeaders: false } to disable it, or use { allow: [...] } or { deny: [...] } to restrict which header values are sent. To control each direction separately, use the { request: ..., response: ... } form, for example { request: true, response: false }.
By default, cookie collection is enabled. On the server, the cookies of incoming requests are sent with error events and server spans. In the browser, the SDK doesn't send cookies unless you enable the httpClient integration, which captures the cookies of failed requests. The SDK replaces the values of sensitive cookies (like token or key) with [Filtered].
To disable cookie collection, set dataCollection: { cookies: false }. You can also restrict which cookie values are sent using { allow: [...] } or { deny: [...] }.
The Sentry SDK doesn't fill the user identity fields user.id, user.email, and user.username automatically. Data that you set with Sentry.setUser() is always sent to Sentry. Some integrations (e.g. User Feedback) may also send data like the user ID, username, and email address when explicitly configured.
The dataCollection.userInfo option controls the identity data the SDK infers on its own, such as the user's IP address (see the next section). It doesn't affect data set with Sentry.setUser().
By default, the SDK sends the user's IP address. To disable it, set dataCollection: { userInfo: false }.
In some integrations such as handleRequest in Astro, the trackClientIp option also controls this. It defaults to the dataCollection.userInfo setting.
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). 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"] },
urlQueryParams: { 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"] },
urlQueryParams: { deny: ["forwarded", "-ip", "remote-", "via", "-user"] },
},
});
The request URL of outgoing and incoming HTTP requests is always sent to Sentry: the scheme, host, and path can't be turned off. Depending on your application, the path could contain PII data. For example, a URL like /users/1234/details, where 1234 is a user id (which may be considered PII).
The query string that's part of the URL is controlled by the dataCollection.urlQueryParams setting described in the next section.
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.urlQueryParams option to control this. Set it to false to disable collection entirely, or use { allow: [...] } / { deny: [...] } to filter which values are sent. Values whose keys match the built-in sensitive denylist (terms like auth, token, password, and secret) are scrubbed automatically. The same rules apply to the query string inside the request URL: values are filtered in place, and false removes the query string from the URL entirely.
Sentry also has some additional server-side data scrubbing in place to remove sensitive data from the query string.
By default, the SDK collects the bodies of incoming requests on the server side. This also covers data taken from the body, like tRPC input and Remix action form data.
Use the dataCollection.httpBodies option to control this. It takes a list of body types to collect: "incomingRequest", "outgoingRequest", "incomingResponse", and "outgoingResponse". All types are included by default, but the SDK currently only captures "incomingRequest" bodies and, for Next.js server actions, "outgoingResponse" bodies. Set the option to [] to disable body collection:
Sentry.init({
dsn: "___PUBLIC_DSN___",
dataCollection: {
httpBodies: [],
},
});
Sentry.init({
dsn: "___PUBLIC_DSN___",
dataCollection: {
httpBodies: [],
},
});
The body size, taken from the content-length header, is always sent, even when body collection is disabled.
On the server-side, the incoming request body is captured by default. You can disable sending the incoming request body by configuring ignoreRequestBody in the HTTP Integration.
On the server-side, the RequestData Integration captures incoming request data including cookies, headers, query strings, request body (data), URL, and user information. The IP address is included when dataCollection.userInfo is enabled.
By default, the SDK doesn't capture response bodies, with one exception: the results of Next.js server actions are collected when dataCollection.httpBodies includes "outgoingResponse", which is the default. To disable this, set dataCollection: { httpBodies: [] } or provide a subset that excludes "outgoingResponse".
The SDK may still send the response body size, taken from the content-length header.
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.
You can enable sending local variables by setting includeLocalVariables: true in the Sentry.init() call. This activates the Local Variables Integration. The integration is added by default in Node.js-based runtimes.
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.
The dataCollection option doesn't affect Session Replay. Because Replay is opt-in by default (it masks everything unless you allow it), while dataCollection is opt-out, the two use opposite privacy models. To avoid changing behavior on a privacy-sensitive feature, Replay's masking and network capture are controlled exclusively by the Replay integration's own privacy options, regardless of your dataCollection settings.
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, remove the Console integration from your integrations config, see the Console 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.
By default, the Context Lines Integration is enabled. This integration sends the surrounding lines of code for each frame in the stack trace. This can include PII data if the code contains PII information.
By default, the Sentry SDK sends database queries to Sentry. The query text is parameterized: literal data values are replaced with placeholders. This applies to SQL and MongoDB queries.
Queries made with the Supabase integration also include the data inside the query by default, such as filter values and write payloads. This data can include PII. Use the dataCollection.databaseQueryData option to control it. Set it to false to redact this data:
Sentry.init({
dsn: "___PUBLIC_DSN___",
dataCollection: {
databaseQueryData: false,
},
});
Sentry.init({
dsn: "___PUBLIC_DSN___",
dataCollection: {
databaseQueryData: false,
},
});
The parameterized query text and structural metadata, such as the database system, the operation, and the table, are always sent. If you turn this option off, you keep the query performance data.
By default, the Sentry SDK sends the data passed to tasks within queues. For Kafka, this is the message key. Producers often use a user ID or a tenant ID as the message key, so this value can include PII.
Use the dataCollection.queues option to control this. Set it to false to stop sending the message key:
Sentry.init({
dsn: "___PUBLIC_DSN___",
dataCollection: {
queues: false,
},
});
Sentry.init({
dsn: "___PUBLIC_DSN___",
dataCollection: {
queues: false,
},
});
Structural metadata, such as the messaging system, the topic, the partition, and the offset, is always sent. If you turn this option off, you keep the queue performance data.
By default, tRPC input is collected because httpBodies includes "incomingRequest" by default. To disable it, set dataCollection: { httpBodies: [] } or use a list that excludes "incomingRequest".
If you exclude "incomingRequest", tRPC input is not collected. You can still opt in per-middleware by setting attachRpcInput: true in the Sentry.trpcMiddleware() options, regardless of the global dataCollection setting.
When you use a GraphQL integration, the Sentry SDK sends the operation name and the operation type to Sentry.
By default, the SDK also sends the GraphQL document (the query or mutation source text). Literal values inside the document are redacted, and the values of GraphQL variables are not collected. Use the dataCollection.graphQL option to turn off the document:
Sentry.init({
dsn: "___PUBLIC_DSN___",
dataCollection: {
graphQL: {
document: false,
},
},
});
Sentry.init({
dsn: "___PUBLIC_DSN___",
dataCollection: {
graphQL: {
document: false,
},
},
});
When using AI integrations, metadata like model ID and used tokens is sent to Sentry.
The content of generative AI inputs (system instructions, prompt messages, tool definitions, and tool call arguments) and outputs (such as completion text and tool call results) might carry personal data. By default, the SDK records both inputs and outputs. Metadata like model ID and token counts is always collected.
The same setting applies to MCP servers instrumented with wrapMcpServerWithSentry. By default, the SDK records the inputs and outputs of tool calls, prompt retrievals, and resource reads. Use the wrapper's recordInputs and recordOutputs options to control recording per server.
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").