PII Scrubbing
Configure privacy rules per project to remove matching data during ingestion, before Tindra stores the supported telemetry fields.
Configure a project
Open Settings > Projects, expand a project, and choose Data privacy. You need project-management permission to change these settings. Enable the built-in patterns, add field paths, and choose Save.
New projects start with no configured server-side field or pattern rules. SDKs may apply their own privacy defaults; review those separately. Changes apply to newly ingested data and do not scrub historical records or previously indexed user metadata.
Block field paths
Field rules match complete dot-separated paths, case-insensitively. They replace the entire value at the matching path with [Filtered]; transaction user fields are cleared when blocked.
| Rule | What it targets |
|---|---|
request.headers.Authorization |
The Authorization header inside an error event's request object. |
request.data.password |
A password in a structured request-data object. It does not parse a JSON string stored as the request body. |
user.email |
Error/transaction user email and a structured log attribute named user.email. |
transaction |
The transaction name. |
password |
A root-level event field or a matching root field in a span-data/log-attributes object. It is not a wildcard for every nested password. |
Event paths start at the payload root. Span-data and log-attribute paths start inside their respective objects. For example, block customer.email inside span data or log attributes, without adding spans.data or attributes to the rule. Arrays are traversed without numeric indexes in the field path.
Pattern scrubbing
Enabled patterns replace matching substrings in supported string values with [Filtered].
| Built-in pattern | Coverage |
|---|---|
| Email addresses | Strings matching the built-in email-address pattern. |
| IP addresses | IPv4 addresses. The current built-in pattern does not match IPv6. |
The UI provides these two toggles and field-path rules. Custom regular expressions are supported through the session-authenticated PATCH /api/projects/{projectID}/privacy endpoint with manage_projects, using scrub_fields and scrub_patterns. Custom patterns must be valid Go regular expressions, at most 200 bytes each; the complete pattern list is limited to 20 entries.
A custom pattern entry has name, pattern, builtin: false, and enabled: true. Treat API updates as complete rule lists and preserve rules you still need. The current UI saves only its two built-in pattern entries, so saving through that panel replaces API-configured custom patterns.
Coverage by data type
| Data | What is scrubbed |
|---|---|
| Error events | Field paths and string patterns across the incoming payload, including request data, breadcrumbs, user context, and incoming stack-frame strings. |
| Transactions | The transaction name, user ID/username/email/name, patterns in span descriptions, and field paths/patterns inside span data. |
| Structured logs | Patterns in the message body, plus field paths and patterns in attributes. |
| Profiles | Patterns in frame metadata such as paths, filenames, function/module names, and packages. Field-path rules do not apply to profile frames. |
Transaction span descriptions and log bodies use pattern rules; blocking a field named body does not remove a log's message. Transaction metadata outside the listed fields is not covered by the transaction scrubber. Log level, trace/span IDs, and the environment/release values extracted during parsing remain unchanged even if a corresponding raw attribute is scrubbed.
Source-map files and code fetched later for stack enrichment are outside the ingestion scrubber. Do not assume that scrubbing an incoming frame also scrubs original source text added when the event is viewed. See Source Maps.
User IDs are not exempt. Scrubbing can change the fallback identity or remove it entirely before user indexing. Prefer a stable opaque ID and consistent rules across related projects; see User Debugging.
Stored data and forwarded data
Passthrough DSN forwards original telemetry content with a rewritten upstream DSN header. Project privacy rules affect Tindra's stored copy, not that forwarded content.
For data that must never leave your application, remove it before SDK capture or in the SDK's appropriate filtering hook. Error-event hooks do not automatically cover logs, transactions, and profiles. Review each signal you enable, then send a controlled test and inspect the stored result.