Smartizy
Get started

Troubleshooting

Events are not showing up. A beacon passes through several gates between the browser and storage, and any one can drop it. Work down this list in order; each step says how to check and how to fix.

No events arriving #

First confirm the beacon leaves the browser at all. Open your browser devtools, go to the Network tab, and load the instrumented page. Look for a request to /v1/events on your ingest endpoint.

  • No request at all. The collector is not configured or not loaded. Check the loader script returns 200, that amb('init') runs with a valid endpoint, and that consent is not blocking (see below).
  • Request blocked by the browser (CORS). Your origin is not allowed. See the next section.
  • Request returns 204 with no data stored. A server-side gate dropped the beacon: a kill switch, an IP filter, a disabled app or tenant, or a rate cap. The sections below cover each.

Origin not in the app's allowed origins #

The receiver applies per-app CORS based on the allowed origins in that environment's ingest policy. If the page's origin is not listed, the browser blocks the beacon before any data is stored.

  • Check. The devtools console shows a CORS error naming the blocked origin, and the request never completes.
  • Fix. Add the exact origin (scheme, host, and port) to the allowed origins for the matching environment under Ingest policies. Remember that allowed origins are per environment, so a staging origin must be in the staging policy.

Missing or invalid ingest token #

When the app requires authentication, the receiver verifies the ingest token on each beacon. A missing, mistyped, or revoked token gets the beacon rejected.

  • Check. Confirm token is set in your amb('init') call and matches a live token on the app.
  • Fix. Copy the secret from the Ingest tokens tab, paste it into init, and if you suspect it leaked or was revoked, rotate it and redeploy with the new value.

If defaultConsent is pending or denied and you never relay a decision, the collector buffers events in the browser and sends nothing. This is the most common cause of a page that loads the collector but shows no network beacons.

  • Check. Look for buffered events with no /v1/events request. Confirm whether your cookie banner ever calls amb('consent', 'granted').
  • Fix. Relay the visitor's choice with amb('consent', 'granted'), or set defaultConsent: 'granted' if consent is not required for your audience. See Consent & privacy. Note a honoured Do Not Track or GPC signal forces denied regardless of the default.

The IP filter dropping your IP #

The receiver drops beacons from blocked IP ranges before they reach storage, answering with a 204. This is how office, QA, and bot traffic is kept out, and it is easy to forget you added your own network to the block list.

  • Check. The beacon returns 204 but nothing is stored, and you are testing from an office or QA network. Compare your public IP against the rules.
  • Fix. Review the tenant-wide and app-scoped rules under IP filters, and remove or narrow any rule that covers your test IP. Test from an IP that is not on the list.

App or tenant disabled or suspended #

A disabled app, or a suspended tenant, makes the receiver acknowledge beacons (204) but store nothing. Quotas can also trip a hard limit that stops ingestion.

  • Check. Confirm the app is enabled on its settings page and the tenant is active. Check whether a quota or hard limit has been reached.
  • Fix. Re-enable the app under Apps, and review Quotas & limits if a cap was hit.