Troubleshooting

Read the browser, in this order

1. The console

The script writes a small number of deliberate, named warnings, and each one names the real problem.

Warning	Means
`[allGood] … is not an authorised origin for this account`	Add that origin to the allowed origins list
`[allGood] the event endpoint refused this page's events`	The tracking key is wrong or revoked, tracking is off, or the origin isn’t allowed
Nothing at all, and no requests	The tag is holding events, waiting on consent

The refusal warning is written once per page — it’s a console, not a log service.

2. The network tab

Filter on _ag. You should see the script load, then a configuration request, then — once consent allows it — capture requests succeeding. The configuration response is the single most useful thing to look at. From your own page, it tells you whether your origin is authorised, whether the form is registered, whether tracking is enabled, what the honeypot field is called, and whether a bot check is required.

3. The console again

window.allgood.version returns a version string if the script loaded.

Symptom → cause

Symptom	Cause	Fix
The browser’s permission check is refused and the submission never happens	The origin isn’t on the list	Add the exact origin — scheme, host, port, no path, no trailing slash
The console warns the origin isn’t authorised	Same	Same. Note `https://brand.com` is not `https://www.brand.com`
One form refuses everything	It isn’t registered	Register it from the form’s Overview
Every submission comes back as a bot	The form requires a bot check and the widget doesn’t cover this hostname	Settings → Web Edge → Sync, then check the coverage chip on that origin
Occasional bot refusals	Something is filling the honeypot — often a browser autofill extension	Check the hidden field is empty at submit time
”Bot protection hasn’t finished loading”	The widget hadn’t rendered when the visitor submitted	Check your CSP allows `challenges.cloudflare.com` for `script-src` and `frame-src`
Submissions refused as invalid	Wrong content type, a body over the size limit, or malformed	Check the request headers and body
Submissions refused for too many attempts	The per-IP budget is 30 a minute. Usually load testing	Wait a minute
Events refused	Tracking is off, no key is issued, or the key is wrong or revoked	Settings → Web Tracking
Events refused for missing consent	Consent is required and the request carried no evidence	Make sure the consent signal is set — see consent behavior
No event requests at all, and no errors	The consent signal never became a yes	Check the signal path, and that your platform writes it
Page views on load but not on navigation	The app routes on the URL hash, or navigates without the History API	Turn off automatic page views and call `track()` yourself
A settings change “didn’t work”	The edge hadn’t caught up	Wait for the chip to read Live at the edge
The GTM tag reports a failure	The injected address doesn’t match the template’s permission	Re-download the template from Settings → Web Tracking
The console complains about `tagmanager.googleusercontent.com`	You pressed Run in GTM’s template editor. Expected	Don’t add that origin. Use the test page
Everything works on the allGood landing page, nothing on the marketing site	The allowed list is empty; hosted pages are same-origin and always allowed	Add the marketing site’s origin
A submission is recorded twice	Your own code posts as well as the script binding the form	Remove one. The script’s guard only covers its own submissions

What you can’t see from the page

Some failures are deliberately opaque in the browser:

A refused origin gets no explanation attached, so the page sees a network error with no readable body. The console warning and the configuration response exist precisely to cover this.
Tracking is fire-and-forget. Acceptance means accepted for processing, not processed — nothing downstream is synchronous, and the page doesn’t wait.

Getting help

Have these ready for support@allgoodhq.com:

Your allGood domain, and the keyId shown beside your tracking key.
The form’s short id, if it’s a form problem.
The exact outcome from the response, and the HTTP status code.
The configuration response from the affected page.
The page’s origin, exactly as the browser reports it.

Use Cases

Deployment and Configuration

Integrations

Read the browser, in this order

1. The console

2. The network tab

3. The console again

Symptom → cause

What you can’t see from the page

Getting help

​Read the browser, in this order

​1. The console

​2. The network tab

​3. The console again

​Symptom → cause

​What you can’t see from the page

​Getting help

Read the browser, in this order

1. The console

2. The network tab

3. The console again

Symptom → cause

What you can’t see from the page

Getting help