> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abtestly.com/llms.txt
> Use this file to discover all available pages before exploring further.
# A/B Testing Diagnostic Reference: Error Codes and Debug Report
> Stable ABTestly diagnostic codes, what each one means and how to resolve it, plus how to generate a copyable diagnostic report from the browser for a support ticket.
This page is the machine readable reference for ABTestly's diagnostics: the
stable error codes the snippet prints, the reasons a beacon can be dropped on
the server, and how to capture a diagnostic report to attach to a support
request.
Error codes are a **stable contract**. The sentence beside a code may be
reworded over time, but the code itself does not change, so it is safe to search
for, alert on, or quote in a ticket.
## Generate a diagnostic report
When something looks wrong, open DevTools on the affected page and run:
```js theme={null}
window.__abtestly.report({ copy: true })
```
With `copy: true` the report is written to your clipboard so you can paste it
straight into a support ticket. Without it, the object is returned to the
console. For a raw string, use `report({ json: true })`.
The report is deliberately small and non sensitive. It contains:
| Field | What it tells support |
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `config` | Snippet version, site id, domain, run mode, SPA mode, GA4 flag, consent mode |
| `consent` | The consent mode and whether consent was granted on this pageview |
| `optOut` | Whether this browser is opted out |
| `assignments` | Each experiment the visitor was bucketed into, its variant, and whether the assignment came from the initial load or an SPA route change |
| `serverAcceptance` | Whether the server confirmed the beacons. On a live page this is `unknown`, because live beacons return `204` with no body; run in preview to see real acceptance |
| `recentEvents` | The last twenty debugger events |
The report never includes the query string (only the path), so a preview token
is never captured. Detailed per event fields stay masked unless you are in
preview mode or have explicitly opted in to sensitive output, the same rule the
[debugger](/preview/dev-debugger) uses.
## Console error codes
These print in the browser console with the `[abtestly]` prefix, in the form
`[abtestly] CODE: message`.
| Code | Level | Meaning | What to do |
| ---------------------------- | ----- | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| `CONSENT_KEY_MISSING` | error | Deferred consent mode is on but no consent key is set, so the snippet will never run. | Set a consent key in Settings, SPA and consent, then re-copy the snippet. See [Consent and deferred mode](/install/consent). |
| `VARIANT_JS_ERROR` | error | A variant's JavaScript threw. | Fix the variant code. The [variation code check](/build/variations) catches many of these before publish. |
| `GLOBAL_JS_ERROR` | error | Your site wide [Global JS](/settings/global-js) threw. | Fix the Global JS. |
| `SNIPPET_CRASHED` | error | The runtime failed to start at all. Rare. | Generate a report and send it to support. |
| `RUNTIME_ERROR` | error | An error happened in a runtime phase. The phase (apply, cleanup, route handling, or an async step) and the experiment id follow the code. | Check the named variant or Global JS, then attach a report. |
| `TRACKGOAL_ORDERID_MISSING` | warn | A refund `trackGoal` call had no orderId, so the event was ignored. | Pass the original orderId. |
| `TRACKGOAL_ORDERID_INVALID` | warn | The `trackGoal` orderId was not usable, so revenue was not deduplicated. | Pass a valid orderId string. |
| `TRACKGOAL_CURRENCY_INVALID` | warn | The `trackGoal` currency was not a three letter code. | Use a code such as `GBP` or `USD`. |
| `TRACKGOAL_REFUNDID_INVALID` | warn | The `trackGoal` refundId was not usable. | Pass a valid refundId. |
| `HOST_NOT_ALLOWED` | warn | The current host is not listed for this site, so nothing ran. | Add the host under Site settings, Domain. |
## Server side beacon drop reasons
A beacon can be sent by the browser and still not be accepted by the server. In
the debugger you will see a `beacon` entry, because the snippet has no way to
know the server's decision; a live beacon returns `204` with no body. So a
`beacon` in the debugger means **attempted**, not **accepted**. The
[blocked IP page](/troubleshooting/blocked-ip) walks through this exact gap.
These drop reasons appear in ingest telemetry and support tooling, not in your
own console:
| Reason | Meaning |
| -------------------- | --------------------------------------------------------------------------------------------------------------- |
| `blocked_ip` | The visitor's IP matched a [blocked IP rule](/troubleshooting/blocked-ip). Expected for your own QA traffic. |
| `invalid_json` | The beacon body was not valid JSON. Usually a truncated or tampered request. |
| `invalid_beacon` | The beacon body was valid JSON but not a valid beacon shape. |
| `site_not_found` | The site id on the beacon does not exist. Usually a snippet copied from a different site. |
| `unknown_experiment` | The beacon named an experiment that is not live. Usually a stale cached assignment; it clears on the next load. |
| `invalid_variant` | The beacon named a variant that does not belong to that experiment. |
| `unknown_goal` | The beacon named a goal that is not configured on the experiment. |
| `missing_identity` | The beacon carried no visitor id. |
| `payload_too_large` | The payload exceeded the size cap. Applies to heatmap snapshots, not exposure or goal beacons. |
| `handler_error` | An unexpected server error. Rare. Contact support with a report. |
A bot heuristic flags suspect requests but **never** drops them. Only an
explicit `blocked_ip` rule you configured discards data.
## Related pages
The ladder for an installed snippet that does nothing.
Why a sent beacon is not always an accepted one.
The full debugger surface behind the report.
Where CONSENT\_KEY\_MISSING comes from.