Metadata capture settings

Decide which event-context fields are recorded — at the project level, server-enforced.

Every error event the SDK sends carries a payload of context fields beyond the stack trace itself: the page URL, the referrer, your release SHA, environment tag, screen size, user identifiers, and so on. Most are useful most of the time, but some teams need to drop specific fields for compliance, contractual, or noise reasons.

GlitchReplay's metadata capture controls let you flip each of these fields on or off per project. Toggles live in Project → Settings → Metadata capture, and the decision is enforced in two places.

Where the toggle takes effect

Each per-project toggle is a single boolean in D1 (e.g. projects.capture_user_email) that drives both halves of the pipeline:

Client-side (advisory). GET /api/{project_id}/config ships the toggles to your SDK. If you wire the response into a beforeSend hook, the field is dropped before the event ever leaves the browser — best for PII fields you don't want on the wire.
Server-side (authoritative). The consumer worker re-checks the toggle when it writes event_facts and the R2 sample. Even if a stale SDK still sends a disabled field, the server strips it before storage. This is the guarantee — toggles off means the data is not retained.

Two-layer enforcement matters because SDK config is cached on the client (5-minute Cache-Control on the config endpoint). The server-side strip closes that window and lets you change a toggle with immediate effect.

Available toggles

Field	Default	What it controls
`capture_url`	on	The full URL where the error fired (`request.url`).
`capture_referrer`	on	The `Referer` header — useful for in-app navigation paths.
`capture_release`	on	Your release / git SHA tag. Required for source-map symbolication.
`capture_environment`	on	`production` / `staging` / `development` tag.
`capture_sdk`	on	SDK name + version that sent the event. Useful when one build is misbehaving.
`capture_screen`	on	Device screen resolution. Useful for layout-specific bugs.
`capture_user_id`	on	Opaque ID from `Sentry.setUser({ id })`. Stored in `event.user.id`.
`capture_user_email`	off	Plaintext email from `Sentry.setUser({ email })`. PII — turn on only if you genuinely need it.
`capture_scrub_query_strings`	on	Strips `?...` from URLs and referrers before storage. Catches API tokens, session IDs, and tracking params that ride along in query strings.

Recommended starting point

Defaults are tuned for low-risk debugging value: every diagnostic field on, every PII field off, query strings scrubbed. If you have a compliance concern, the most common changes are:

HIPAA / health data: turn off capture_url (URLs commonly contain patient or record IDs in path segments) and capture_referrer. Keep capture_scrub_query_strings on.
EU / GDPR with no DPA for emails: leave capture_user_email off (the default). Use capture_user_id with an opaque hash instead.
Marketing-heavy site with utm_* params you want to keep: turn off capture_scrub_query_strings and pair it with a PII scrubbing rule that strips only the sensitive params.

Interaction with PII scrubbing rules

Capture toggles are coarse-grained — the field is either captured whole or dropped whole. For finer control (e.g. "keep the URL but redact the token= param") use PII scrubbing rules, which run server-side on the captured fields. The two layers compose: a toggled-off field is dropped before any rule even sees it.

Next: PII scrubbing rules for finer per-field redaction, or session replay for the recording side of the pipeline.

← Back to home