Data & privacy
Data & privacy in the Settings area (Apps & data) — route /settings/data-privacy.
Data & privacy lives in the Settings area of the dashboard, under Apps & data.
At a glance#
| Dashboard route | /settings/data-privacy |
| Area | Settings (settings) |
| Group | Apps & data |
| Platforms | Available for every app platform. |
What it does#
Data privacy is the page with the most consequential settings in the product. It has three parts.
Redaction — what gets stripped from captured data before it is stored. Toggles for emails, IP addresses and secrets, plus your own custom terms. Each can be applied independently to webhooks, tickets and exports, so data leaving the platform can be redacted even where the stored copy is not. A live sample shows the effect of your current rules.
Retention — per data type, how many days data is kept, within a permitted minimum and maximum. Each policy shows when it last ran and how much it deleted.
Retroactive redaction — applying redaction to data already stored.
When to use it#
Before your first production release, not after. Redaction is forward-looking by nature: a rule added today does not un-capture yesterday, and retroactive redaction is a repair rather than a substitute for getting it right first.
Workflow#
Turn on the categories you need before any real traffic
Emails and IPs first. Then add custom terms for anything your domain treats as sensitive — an account number format, an internal hostname, a token prefix.
Read the live sample
It shows your rules applied to representative text. This is the cheapest possible way to find out that a rule does not match what you thought it did.
Decide the outbound toggles separately
Webhooks, tickets and exports each carry data outside the platform. Applying redaction to those is a different risk decision from what you store, and all three are separately controllable.
Set retention to the shortest period that is useful
Data you do not keep cannot leak, cannot be subpoenaed, and does not cost you. Retention is a security control, not just a storage setting.
Permissions and prerequisites#
Requires an administrative role. Retention purges and redaction changes are recorded in the audit log.
Limits and edge cases#
Forward-only. New rules apply to new data. Use retroactive redaction for what is already stored.
Retention is bounded. Each data type has a minimum and a maximum; you cannot set an arbitrary period.
A purge is permanent. There is no recovery, which is the point.
Replay needs its own attention. Recordings capture the screen — see Session replay for masking, which is configured in the SDK rather than here.
Troubleshooting#
Sensitive data is in stored events. Enable the relevant rules, run retroactive redaction, then fix the instrumentation so it is not sent at all. Do all three, in that order.
A custom term is not being redacted. Terms match literally. A value that varies — an id, a token — needs to not be captured rather than to be listed.
Retention will not go as low as I want. There is a floor per data type.
Where the data comes from#
Retention and redaction settings apply going forward, not retroactively.
From the SDK
Served by
Replay redaction
Preferences