Privacy: RUM and session replay

What is collected

• RUM: page views, Core Web Vitals, errors (message, stack frames, debug ids), clicks and frustration signals (selector path only, no element text), route templates, release, coarse device class, browser and OS, country (from an operator GeoIP header or file), a salted hash of the user id.

• Replay: DOM snapshots and mutations, pointer and scroll events, console and network metadata, recorded in the browser at the project's mask level (default strict: all text and inputs masked).

• Profiles: stack samples. Command-line arguments are stripped by the scrub policy.

What is never collected

• Password, card number and one-time-code inputs: never recorded, and removed again at wt-edge.

• Element text in frustration events, request or response bodies, cookies and Authorization headers.

• Routes listed in excluded_routes (for example /admin*): no events and no URL appear in any chunk.

• Raw user ids: only a salted hash leaves the browser.

Defaults and floor

• Replay is off until a project admin turns it on. The default mask level is strict.

• Each project has a mask-level floor. A request below the floor is refused (the edge returns 422). Lowering masking (for example to relaxed) needs ManagePrivacy (ProjectAdmin); an Engineer's attempt returns 403.

• Origins must be on the publishable key's allowlist; other origins get 403 for RUM, replay and OTLP.

• Privacy changes are audited without the values of any secret.

Deletion

• Turning replay off makes the next chunk request return 404 replay_disabled (servers before 2026-11 answered 403; the browser SDK stops on both).

• DELETE /v1/projects/{p}/replays/{session} removes the S3 prefix replay/{project}/{session}/ and then the metadata. Bulk delete by cutoff and legal holds are in replay-operations.md.

• Retention is per project; a daily job removes expired objects and orphans.

Known limits

Server-side replay scrubbing covers password and card/OTP inputs by structure. A custom component that renders a secret as plain text is protected only by client masking (strict, the default) and block selectors. Add a block selector for such components.

PII scanning at the gateway

The gateway masks personal data and secrets in log bodies and in the string attributes of logs and spans before anything is stored. A new project starts with every secret kind (tokens, keys, private keys) plus email, phone, card and iban, all in hash mode (replace on a server without WT_SECRET_KEY). Step 4 of Get started, "Turn on PII scanning", lists these rules and lets you choose the signals to scan (logs, traces); projects created before the defaults existed turn them on there. Settings > Privacy and processing > PII detectors changes kinds, actions, scopes, safe fields and signals.

API: GET/PUT /v1/projects/{prj}/redaction/detectors, with signals (logs, traces; absent means both, [] means none). Matches are counted as wt_redaction_matches_total{detector,signal,service} so a team can alert when a service starts leaking.