Troubleshoot a missing banner

A banner can be absent because its script did not run or because the runtime decided not to show it. Separate those cases before changing configuration.

Start with a clean visit

Open the page in a private window or clear CookieBeam cookies and local storage. A valid stored consent record can suppress the automatic banner display.

Use the exact page and hostname where the problem occurs. Regional decisions and authorized-domain checks depend on the current request.

Check the loader and bundle

Open the browser network panel and reload the page. Find the CookieBeam loader and the latest.js request.

Check these items:

1. The public Banner ID in the URL matches the banner.
2. Both requests complete without a network error.
3. The requested path contains the intended environment slug.
4. The site's content-security policy permits the CookieBeam CDN.
5. The console does not report Domain not authorized or Failed to load banner script.

The loader stops before requesting the banner when the current hostname is not in the compiled authorized-domain list. An empty authorized-domain list allows any hostname.

For a new environment with no published version, the dashboard returns default bundle URLs. For a published non-production environment, the current environment loader still requests default/latest.js. Load the environment-scoped latest.js directly when you need to isolate the non-production snapshot.

Check the publish result

Open the target environment and version history. Confirm that the intended version is selected. For a direct publish, confirm its build status is built. For a promotion, confirm that the promotion returned a built result because promotion does not update the reused version's stored status.

Publishing saves the version pointer before building the asset. A selected version with a failed build status does not mean the CDN received that version. Rebuild the current default version, or publish to the affected environment again.

Production publishes also update the default bundle aliases. Non-production publishes do not.

Check regional visibility

A regional rule or fallback can intentionally hide the banner. When the CDN regional gate takes that path, it sets:

window.CookieBeamConsent.bannerHidden === true
window.CookieBeamConsent.reason === 'regional_setting'

Check the country and region used for the request. A missing or unmatched location applies the configured regional fallback rather than a named rule.

On banners using the core runtime, add ?cb_debug=1 to the page URL and reload. The console report includes geo source, matched rule, fallback reason, resolved mode, shouldShow, stored-consent state, variant, and script URL.

You can also inspect the current snapshot without the query parameter:

window.CookieBeamConsent.debugInfo()

The debug API is attached by the core runtime. A legacy-runtime banner may not expose it.

Check runtime errors

Inspect these values in the console:

window.CookieBeamConsent
window.__cb_precomputed_regional_behavior
window.__cf_country
window.__cf_region

The core wrapper stores a startup error on window.CookieBeamConsent.error. It also writes console errors when the core library is unavailable, fails to load, or fails during startup.

If the loader and bundle both load but the banner remains absent, compare the following evidence:

• bannerHidden and the regional behavior for an intentional hidden result.
• debugInfo().consentMode.hasStoredConsent for a stored choice on the core runtime.
• The loaded script URL for an environment or variant mismatch.
• The console error and network request that failed.

Do not republish until you know whether the failure is asset delivery, domain authorization, stored consent, or regional visibility. A republish changes the version history but does not clear visitor storage or change the visitor's location.