Troubleshoot telemetry and runtime policy changes
Interpret no-data states and recover safely from validation, publication, or propagation failures.
Last updated 2026-08-07
What you'll achieve
- Interpret missing telemetry honestly
- Resolve policy conflicts before publication
- Roll back through immutable policy history
When telemetry appears empty
Confirm the project, environment, time window, release, region, operation, and filters. Check whether the UI reports no traffic, delayed ingestion, sampling, retention expiry, plan limits, or temporary unavailability. Do not interpret unavailable or delayed telemetry as zero traffic.
When a policy change fails
Validate the draft and inspect the effective policy, platform floors, plan entitlements, simulation results, revision, and document hash. A conflict means the reviewed input changed or violates a stronger limit; resolve it and review again. Do not create a new mutation identity merely because publication returned ambiguously.
If propagation does not complete, keep the prior effective policy as the recovery reference and inspect edge acknowledgements by region. Rollback creates a new immutable version. Escalate with policy revision and hash, release, affected region, failure state, and UTC time—never secret values or raw customer data.
Help improve this page
Sign in to send page-specific feedback. For account-specific help, email support@blinkhost.me.