Troubleshooting
SiteWall data is missing or incomplete
Diagnose missing providers, resources, sessions, or Exposure Map relationships from project context outward.
Last reviewed September 12, 2026
Troubleshooting overview
Troubleshoot SiteWall from context outward: capture the project, domain, page, time, browser, record link, and recent change; confirm installation and traffic; verify filters and observation scope; inspect the underlying provider, resource, session, policy, or delivery record; then escalate with the preserved evidence.
Diagnostic procedure
- 1.
Open the correct project and page
Select the intended project, then open the SiteWall area associated with Troubleshooting overview. Confirm the project and monitored domain before continuing.
- 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.
How to collect context
Review how to collect context in the active project, follow the linked source record, and preserve its observation, interpretation, and owner decision context.
- 4.
Escalate safely
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.
- 5.
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.
- 6.
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.
No providers or resources appear
If no providers or resources appear, confirm the intended project and exact domain, verify that the initialization code loads on the page without browser errors, generate real page traffic, check blockers and content-security restrictions, and allow for processing. Reinstall only after isolating the failed step.
Diagnostic procedure
- 1.
Open the correct project and page
Use the project selector to choose the website you intend to review, then open Providers 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.
Installation
Review installation in the active project, follow the linked source record, and preserve its observation, interpretation, and owner decision context.
- 4.
Project
Confirm the active organization and project, the person or team accountable for the change, and the role required to perform it. Verify the resulting access or ownership state from a second authorized context when practical.
- 5.
Domain
Compare observed browser access with the resource’s documented business purpose and the journeys that depend on it. Observed use can inform a least-privilege baseline, but unobserved use may still occur in untested states.
- 6.
Traffic
Open a representative session and record its page, time, browser context, and observed resources. Use it to establish that the behavior occurred in that captured journey, not that it occurred for every visitor.
- 7.
Processing checks
Review processing checks in the active project, follow the linked source record, and preserve its observation, interpretation, and owner decision context.
- 8.
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.
- 9.
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.
A known resource is missing
A known resource may be missing because the monitored page or journey was not exercised, the resource loads conditionally, the time or project filter is wrong, consent or browser state changed, the request was blocked, or processing is incomplete. Reproduce the exact loading condition and inspect the resulting session.
Diagnostic procedure
- 1.
Open the correct project and page
Use the project selector to choose the website you intend to review, then open Inventory 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.
Scope
Keep the selected project, monitored pages, traffic paths, and observation period attached to the result.
- 4.
Page coverage
Confirm the approved page list, authentication or initialization requirements, schedule or run state, and resulting records. A configured page is not evidence that every conditional browser state was exercised.
- 5.
Loading conditions
Review loading conditions in the active project, follow the linked source record, and preserve its observation, interpretation, and owner decision context.
- 6.
Timing
Compare like-for-like sessions and treat captured timing as context, not a complete causal proof.
- 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.
Exposure Map is incomplete or crowded
For an incomplete Exposure Map, confirm project, traffic coverage, and filters. For a crowded map, group by provider, focus one node, pan and zoom, and trace one relationship at a time. Compare important edges with provider, resource, or session details.
Diagnostic procedure
- 1.
Open the correct project and page
Use the project selector to choose the website you intend to review, then open Dashboard 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.
Filters
Narrow the current project’s records before interpreting totals or opening a detail view.
- 4.
Grouping
Review grouping in the active project, follow the linked source record, and preserve its observation, interpretation, and owner decision context.
- 5.
Observation availability
Review observation availability in the active project, follow the linked source record, and preserve its observation, interpretation, and owner decision context.
- 6.
Layout
Review layout in the active project, follow the linked source record, and preserve its observation, interpretation, and owner decision context.
- 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.
Sessions are missing
If sessions are missing, confirm the project, monitored domain and page, installation, runtime traffic, query and time range, browser blockers, and processing delay. Reproduce a fresh journey and retain its timestamp so the expected record can be located precisely.
Diagnostic procedure
- 1.
Open the correct project and page
Use the project selector to choose the website you intend to review, then open Sessions 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.
Runtime traffic
Open a representative session and record its page, time, browser context, and observed resources. Use it to establish that the behavior occurred in that captured journey, not that it occurred for every visitor.
- 4.
Time range
Compare the first, last, and event timestamps with the investigation or reporting window. These values describe SiteWall observations for the active project and do not establish activity outside the captured period.
- 5.
Project scope
Keep the selected project, monitored pages, traffic paths, and observation period attached to the result.
- 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.