Connect
Masking
Mandatory masking runs on every ingestion path before anything is stored or forwarded. Administrators can add masking rules; the mandatory ones cannot be removed or bypassed.
How it works#
Masking uses an allowlist, not a blocklist. Each source has a privacy profile that lists the fields it may emit for each type of event. Anything not on the list is dropped before the data is masked and stored. Fields that are on the list are then masked by pattern, and the result is what every later stage sees: storage, search, detection, the copilot, and every destination.
There is no separate unmasked path. Nothing unmasked is written to storage, to a persistent export queue or to a destination, and the same controls apply to every route into MonitOps, including provider plugins, internal services and inbound receivers. Masking runs after any processing step that can introduce data and before any durable write or delivery. A processing step added by an administrator cannot move itself past it.
What is always removed#
| Category | Handling |
|---|---|
| Email addresses, IP addresses | Removed |
| Phone numbers | Removed |
| National identifiers | Removed |
| Usernames and display names | Never emitted |
| Record contents | Never emitted |
| URL query strings, fragments and user information | Stripped from every URL |
| Customer-valued path segments | Replaced; only configured path templates are kept |
Masking covers nested log bodies, attributes, scope and resource names, span names, status and events, metric names and descriptions, and exemplar attributes.
What is kept#
User identifiers are kept when they are opaque platform identifiers that pass validation. They let you follow an actor through an incident without revealing who the person is. Configured operational templates, such as the shape of an endpoint path, are kept so that logs stay readable and groupable.
Administrator rules#
Administrators can add masking rules on top of the mandatory set, for example to mask a pattern specific to their estate. Added rules narrow what is stored; they cannot widen the profile or remove a mandatory step.
Quarantine#
A record that cannot be admitted safely or correctly is quarantined with masked diagnostics instead of being dropped or stored as received.
| Reason | Meaning |
|---|---|
enforced_metadata_conflict | The record's value conflicts with a value the source's policy enforces |
environment_alias_conflict | The record carries conflicting values for the environment under its canonical and legacy names |
Rejection is decided per resource group. Other groups in the same request are admitted. The sender receives a partial success with the number of rejected records; see OTLP endpoint. A quarantined record never drives a query, a signal or a service map edge, however well it would otherwise resolve.
A quarantine entry holds the masked record, its position in the request, the reason and a fixed field path. It does not hold the rejected body, free text from the sender or the sender's conflicting value. Diagnostics use fixed reason codes, not arbitrary error text.
A request that cannot be turned into safe typed records at all, because its format is invalid or privacy rules cannot be applied, is rejected as a whole. No recoverable payload is kept.
Correct and reprocess#
- Open Sources and find the quarantined records and their reason.
- Correct the sender's metadata, for example the environment attribute or the enforced value.
- Reprocess the quarantined records by record identity.
Reprocessing is authorized for the source and references the original record by its identity. A sender cannot claim another tenant's records by supplying an identifier, and an existing entity is never overwritten by reprocessing.
What you see in the console#
Sources lists the quarantined records and the diagnostic for each, with the reason code and the masked content. Logs and traces show masked values, and some attributes are hidden from the viewer role altogether. The copilot reads the same masked data through the same permission checks. See Copilot.
Limits and defaults#
- Masking is by pattern and allowlist. Unknown free text cannot be declared de-identified by pattern matching alone, so text that is not covered by an approved template is replaced or rejected, not passed through.
- Masking happens before forwarding, so log destinations receive masked, normalised records only. See Destinations.
Failure states#
| State | Behaviour |
|---|---|
| A field is not on the profile | It is dropped before masking and storage |
| A policy conflict in a resource group | The group's records are quarantined with the reason; other groups are admitted |
| A privacy rule cannot be applied | The whole request is rejected and nothing is retained |
| Masking diagnostics would reveal what was removed | They are suppressed; only fixed codes are shown |
Related#
Last updated October 2026