docs: Add "Data Scrubbing" spec, update docs on parametrization and scrubbing

[s1gr1d]

Defines which sensitive data the SDK scrubs and which data Relay scrubs. It also defines the terms and separates scrubbing from parameterization.

This follows our meeting discussion @mydea @Dav1dde

• New spec "Data Scrubbing":
  • New: https://develop-docs-git-sig-data-scrubbing-parametrization.sentry.dev/sdk/foundations/data-scrubbing/
  • Before: https://develop.sentry.dev/sdk/foundations/data-scrubbing/
  • Parameterization is for better grouping and search. Scrubbing replaces a sensitive value with [Filtered]. The purpose decides which one applies
  • The SDK scrubs data that it knows is sensitive at the time of collection (keys, headers, cookies, query params)
  • The SDK does not parse payloads only to scrub them. Relay does heuristic and parse-based scrubbing
  • Fields that Relay cannot scrub (span name, metric name) must not contain sensitive data
• Data Collection: SDKs attach text bodies unchanged. Relay scrubs them.
• Queries Module: "Query Scrubbing" is now "Query Parameterization". The SDK uses the driver's parameterized query or replaces literals with ?. If it does not do this, it may send db.query.text
• Structuring Data and Metrics: Use dataCollection instead of sendDefaultPii. Fixed outdated links.

Tested (what do we see in Sentry)

JS app on SDK v11. Raw values set in span attributes with beforeSendSpan: http.request.body.data, http.response.body.data, http.request.header.cookie, http.response.header.set-cookie, http.response.header.x-probe-*.

• Relay does not parse body attributes. A JSON body that contains password became [Filtered] as a whole.
• Card numbers are replaced in place (cart=[Filtered]).
• Known session cookies (session=…) are scrubbed. connect.sid is not: Scrub the connect.sid session cookie relay#6497.
• Emails, IPs, and JWTs are not scrubbed

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
develop-docs	Ready	Preview	Oct 19, 2026 1:05pm UTC

1 Skipped Deployment

Project	Deployment	Actions	Updated
sentry-docs	Ignored	Preview	Oct 19, 2026 1:05pm UTC

[github-actions]

Please update the IS YOUR CHANGE URGENT? section of the PR description:

• Select exactly one option.
• If you selected an urgent or other deadline, provide the date as YYYY-MM-DD.

This information helps the Docs team prioritize your review.

[cursor]

The plan checks that rewritten spec pages still serve, and that new render errors do not appear.
An issue escalates when HTTP 5xx appear, 404 share rises, or spec-page render errors appear.

Services: develop-docs.

Mention @change-monitor in a comment to update the plan.

Plan

What changed

Requests to the Data Scrubbing spec now define parameterization versus scrubbing. They also split SDK work from Relay work.
SDK body rules now attach text bodies unchanged. Relay applies heuristic scrubbing to those bodies.
Query span names now use parameterized queries. They use a fallback when parameterization fails.
This change is live after the develop-docs service deploys. Deploy config maps the Vercel develop-docs project to that catalog id.

Risk

A failed MDX compile can block the production deploy.
A runtime render error can blank every document page on the catch-all route.
Renamed section anchors can strand old hash links. Those misses do not return HTTP 404.

Intended effect

This change rewrites specification text. No telemetry proves the new terms appear on the page.
HTTP 200 on the catch-all document route is a weak proxy that pages still serve.
absent looks like 200s continuing while the six rewritten paths 404 or fail to render.
Per-URL views are not available. All pageloads share transaction /:path*?.

Signal	Baseline	Rule	Source
HTTP 200 share on http.server	78-79% (62 of 79 sampled spans) in 2026-10-11T10:50:08Z to 2026-10-12T10:50:08Z	Hold near that share. Treat a drop with a 404 rise as absent intended effect.	Sentry sentry / develop-docs, span.op:http.server environment:production, group by http.status_code
Pageload count on /:path*?	563 sampled pageloads in the same window	Hold near this volume after a weekday adjustment. A collapse with 404 rise means the new pages are not serving.	Sentry sentry / develop-docs, span.op:pageload environment:production

This 24h window includes a Sunday. Weekday traffic may be higher.
Client pageloads use a 0.3 sample rate. AI-agent traffic uses a 1.0 sample rate.

Regression watch

A bad spec MDX file can 404, return 5xx, or throw in the catch-all document renderer.
Watch HTTP status on that route and new client errors. Ignore the standing Algolia Insights 401 noise.

Signal	Baseline	Rule	Source
HTTP 5xx share on http.server	0 of 79 sampled spans in 2026-10-11T10:50:08Z to 2026-10-12T10:50:08Z	Hold at zero. Escalate if any 5xx span appears.	Sentry sentry / develop-docs, span.op:http.server environment:production, group by http.status_code
HTTP 404 share on http.server	21-22% (17 of 79 sampled spans) in the same window	Hold near that share. Escalate if the share rises above the band. The share may include crawler misses.	Same query as the 5xx row
Client error events	32 events in the same window. Top title is Algolia Insights 401 at 14 events. Spec component and MDX titles are 0.	Escalate if new titles mention SpecSection, SpecMeta, hydration, or MDX. Do not escalate on Algolia Insights 401 alone.	Sentry sentry / develop-docs errors, environment:production, group by title

If 5xx or 404 share rises, inspect error logs for MDX compile failures and missing spec components.

Not observable

Per-URL loads of the six rewritten paths. Pageload transaction names collapse to /:path*?.
Whether the new spec wording is correct.
Broken hash links to #query-scrubbing and #sensitive-data.
Search-index lag for renamed headings.

Get Slack DMs about this change: cursor.com/automations/rollouts

[Dav1dde]

I think I'd prefer a split between client side/SDK scrubbing and server side scrubbing (Relay) and using that terminology instead of mentioning Relay directly.

[Dav1dde]

Technically on the server side we also allow for different replacements than [Filtered] this is just our default for the default rules.

[Dav1dde]

This largely depends on the users project and organization settings and I'd instead link to our server side scrubbing docs.