Troubleshooting
A policy is ineffective or breaks the website
Resolve precedence and deployment problems, restore expected behavior, and preserve the failing evidence.
Last reviewed September 12, 2026
A policy does not appear effective
If a policy appears ineffective, first confirm the active project and resource identity. Then inspect resource, provider, and global layers for inheritance; verify the supported enforcement code is active on the affected page; reproduce with a fresh representative session; and check Issues, Anomalies, and Alerts for the same time window.
Diagnostic procedure
- 1.
Open the correct project and page
Use the project selector to choose the website you intend to review, then open Policies in the left navigation. Confirm the organization, project, and monitored domain before interpreting a record or changing a control.
- 2.
Preserve the failing state
Capture the exact symptom, affected URL, browser, time, record link, active filters, effective policy, and most recent deployment or configuration change. Avoid refreshing away evidence you may need.
- 3.
Inheritance
Distinguish the configured value at each layer from the effective value resolved through Global, Provider, and Resource precedence.
- 4.
Enforcement path
Read the configured value at Global, Provider, and Resource layers and identify the resolved effective state. Apply the narrowest approved change, validate critical journeys, and retain the previous state for recovery.
- 5.
Scope
Keep the selected project, monitored pages, traffic paths, and observation period attached to the result.
- 6.
Cache/deployment checks
Preserve the failing state, test the most local dependency first, and make one reversible change at a time. Reproduce the original journey after each check and stop when the evidence points to a different layer.
- 7.
Retest after one reversible change
Reproduce the same page and journey after each check. Compare the new record with the preserved failing state, and stop when the evidence points to a different component or owner.
- 8.
Prepare an escalation packet if unresolved
Include the project, URL, time range, browser, record links, current and expected states, checks completed, changes reverted, and the team that owns the next dependency.
Website behavior changed after a policy
If website behavior changes after a policy update, stop expanding the change. Record the affected URL, journey, resource, policy layer, and time; restore the last known working inherited or explicit state; verify recovery; then reintroduce the minimum restriction one capability or destination at a time.
Diagnostic procedure
- 1.
Open the correct project and page
Use the project selector to choose the website you intend to review, then open Policies in the left navigation. Confirm the organization, project, and monitored domain before interpreting a record or changing a control.
- 2.
Preserve the failing state
Capture the exact symptom, affected URL, browser, time, record link, active filters, effective policy, and most recent deployment or configuration change. Avoid refreshing away evidence you may need.
- 3.
Identify affected resource
Confirm the URL or domain, provider association, first and last observation, and the project in which the entity was recorded. Open the linked detail record; a display name or enrichment label is not proof of ownership or approval.
- 4.
Restore safely
Read the configured value at Global, Provider, and Resource layers and identify the resolved effective state. Apply the narrowest approved change, validate critical journeys, and retain the previous state for recovery.
- 5.
Retain evidence
Preserve source, time, project, and transformation context and separate the technical record from the reviewer’s conclusion.
- 6.
Retest after one reversible change
Reproduce the same page and journey after each check. Compare the new record with the preserved failing state, and stop when the evidence points to a different component or owner.
- 7.
Prepare an escalation packet if unresolved
Include the project, URL, time range, browser, record links, current and expected states, checks completed, changes reverted, and the team that owns the next dependency.