After you paste the tag, the install page in the app watches for your first event and flips state the moment one arrives. You do not need to go looking in the dashboard.
What you should see
The install page shows one of two states.
Waiting for your first event — the tag has never fired for this site. The page keeps polling; leave it open.
Connected — an event has arrived. The page shows when, and gives you a link straight into that site's dashboard.
20s, screen capture. Start on the install page in the "Waiting for your first event" state. Paste the snippet into a page in a second tab, load that page, cut back and show the install page flipping to "Connected" with the timestamp. Light theme, desktop 1440px.
The install page in the "Waiting for your first event" state, with the snippet above it and the polling indicator. Light theme.
The same install page after the first event, showing "Connected", the time of the first event, and the link to the dashboard. Light theme.
How long it should take
A few seconds. The tag sends a view on page load, the collector records it,
and a database trigger stamps the site's first_event_at in the same
transaction. There is no batching and no scheduled job in between.
If you have just pasted the tag:
Open your site in a new tab and load a page.
Come back to the install page.
If it is still waiting after a minute, something is wrong, and it is almost always one of five things.
If it does not flip
Work down this list in order — it is ordered by how often each one is the cause.
1. The change is not live yet. Webflow, Framer, Ghost and Squarespace all apply custom head code to the published site, not to the editor preview. Publish, then load the published URL, not the preview URL.
2. You are testing on localhost.
Tracking is disabled on localhost and 127.0.0.1 unless you opt in. Add
data-allow-localhost="true" to the tag while you are testing — and see
Localhost and development first,
because the events you generate this way land in your real numbers.
3. Your own browser is being excluded. If you set the ignore flag on this browser, or added your own IP to the site's exclusions, your own page loads produce nothing. See My own visits are being counted for both switches, in reverse.
4. An ad blocker in your browser.
uBlock Origin and similar block requests to analytics hostnames. Open your
browser's network tab, load a page of your site, and look for a request to
/api/events. If it shows as blocked, that is your answer. Try in a private
window with extensions off, or move to
serving from your own domain.
5. Your platform's head field needs a paid plan. On Wix, Bubble and Squarespace, custom code is gated behind a paid tier. The field accepts your paste, saves it, and then the code is simply not emitted on the published page. There is no error. See Head-field platforms for which plan each one needs.
If none of those apply, No events are showing up walks through the rest, including Content Security Policy and origin mismatches.
Confirming it yourself
You do not have to trust the page. Load your site, open the browser's developer tools, go to the Network tab, and reload:
There should be a request for
t.jsreturning 200.There should be a
POSTto/api/eventsreturning 202 Accepted.
202 rather than 200 is intentional — it means "recorded, and the bookkeeping
is finishing". It is a success.
Browser DevTools Network tab on a site with TrueStat installed, showing the t.js request (200) and the /api/events POST (202) with the response body {"ok":true}. Dark theme DevTools, any browser, cropped to the two rows and the status column.
Any other status has a specific meaning — see Verifying it works.