Troubleshooting: "I Sent an Event, Got HTTP 200, But See Nothing"
A 200 OK response only means the request was accepted and queued - it does not mean the
event reached your dashboard, ClickHouse, or Facebook/TikTok. Work through this checklist in order;
each step rules out one specific cause.
For the full picture on processing timing and deduplication semantics, see Timing & Deduplication on the Events Overview page.
1. Check the Workspace's Errors Tab
Before anything else, open your workspace in the admin panel and check Event feed → Errors. Most "nothing showed up" reports turn out to be a validation rejection, an authentication failure, or a downstream forwarding error that was already recorded there - the event never silently vanished, it failed with a reason that's visible in the log. If you see an entry there, its message tells you exactly what to fix; you don't need the rest of this checklist.
2. Conversion Events Are Delayed ~10 Seconds
Conversion-type events (transaction.charge, product.addToCart,
begin_checkout, etc.) are intentionally held in the processing queue for
10 seconds (PROCESSING_DELAY_SECONDS in the event worker's
ConsumeEventsCommand) before being written to ClickHouse and forwarded to Facebook
CAPI / TikTok Events API. The delay exists so the visitor's profile has a chance to pick up
fbp/fbc from the JavaScript SDK's page.view event before the
conversion event reads that profile - without it, server-side conversions would frequently race
ahead of the browser pixel and lose match quality.
page.view and profile.update events are the exception: they're processed
immediately, precisely because conversion events depend on them being enriched first.
What to do: wait at least 10-15 seconds after sending a conversion event before concluding it's missing.
3. Events Older Than 1 Hour Are Discarded
Once an event has been sitting in the processing queue for more than
1 hour (MAX_EVENT_AGE_SECONDS = 3600), the event worker logs it as
stale and discards it instead of forwarding it downstream with an outdated timestamp.
This is the most common cause of "I replayed old orders and nothing showed up." If you're
backfilling historical transactions, recovering from a queue outage, or resending events from a
dead-letter store, anything queued more than an hour before the worker actually processes it will
be silently dropped even though the original POST returned 200 OK. There
is currently no bulk-backfill exemption from this window - send historical data through a different
path (e.g. directly into ClickHouse) if you need to import orders older than an hour.
4. The Domain Must Be Verified
If you're tracking from a custom subdomain (e.g. axi.yourdomain.com), events sent to an
unverified domain are rejected before they're even queued. Check
Workspace settings → Tracking & domains and confirm the domain shows "Verified".
Note also that "Verified" only proves DNS ownership - a separate, asynchronous process still needs to provision routing and a TLS certificate before the domain serves traffic at all, which can itself look like "nothing is happening." See Domain Configuration: Propagation Delays for that timeline.
5. A 200 Can Still Mean "Dropped as Bot"
AxiTrace's bot-detection pipeline runs first in the middleware chain - before authentication,
before CORS, before validation. A request classified as a bot receives
200 {"status": "ok"} and is dropped immediately; it never reaches your Errors tab, your
dashboard, or ClickHouse. This is by design (a real error response would let bots learn they were
detected and adapt), but it means a "successful" response from a script, a curl test, or a
headless-browser tool tells you nothing about whether the event was actually recorded.
See Troubleshooting: Testing with curl for how to identify a bot-dropped request and how to test with a realistic browser User-Agent instead.