Troubleshooting

1. Check that the snippet is on the page. The network tab should show a request to /track.js and a request to /api/collect.
2. Check the website id in the snippet. It must be the id of the website you are looking at, and it must match the id in the Developers page of that website.
3. Check that the website is active. A paused or archived website stops accepting events and the report stays empty.
4. Check whether a path rule excludes the page. A page that matches an excluded path is dropped on the server, so nothing arrives and nothing is stored.
5. Check the origin rules. If a hostname is on the allowlist of the website, a request from another origin is refused and the network tab shows a forbidden response.
6. Open the page in a normal browser window. A headless browser, a preview service or a crawler is filtered on the server and is never recorded.

• Check that the script is not installed twice, for example once through a component and once in the markup. The script refuses to initialise a second time, but a second copy with a different id would send to a different website.
• Browser events carry an identifier and the server stores each identifier once, so a repeated request is not counted twice.
• Server events are different: the server generates a new identifier for every request it accepts. If your own code retries a request, the retry is a new event. Send the same event from a single place, or use the revenue endpoint with an idempotency key when the value is money.
• Check the time zone of the report. A day boundary that moves events between two days can look like a duplicate.

Every day in the report is the calendar day of the website timezone, and every range starts at local midnight. If your traffic arrives at 11pm and the report shows it on the next day, the timezone of the website does not match the timezone you expect.

Change the timezone in the site settings. The change applies to the reports from then on. The days that were already bucketed with the previous timezone are not rewritten, so a range that crosses the change contains one boundary that used the old rule.

Requests whose user agent looks like a crawler, a preview service, a monitoring probe or an automation tool are dropped at ingestion. That includes headless browsers, so a Lighthouse run or a Playwright test never shows up in a report.

The command line tools are on that list as well. A request made with curl is dropped, and the answer says so: the endpoint returns the number of accepted and the number of rejected events, and a rejected event is not stored. Send a browser user agent when you test with curl.

This is deliberate. A test that needs to be recorded should be sent through the server-side event API, which is not filtered by user agent, or with the test event tool on the developers page, which records the event in your own installation.

The ingestion endpoint answers with a forbidden error when the origin of the request is not one of the hostnames the website accepts. The message names the hostnames that are accepted.

• Check that the domain of the website is the hostname in the address bar. The domain set when the website was created is always accepted. Thewww prefix is ignored, and a subdomain of the domain is accepted.
• Check that the hostname was verified. A hostname that was added but never verified does not restrict the origin yet.
• Check that the tracking id belongs to the website whose domains you configured. The id and the domains travel together.
• If the script runs somewhere you cannot list, for example a hosted preview, set the origin policy of the website to any origin in the site settings. Events are then accepted from any origin, so use it only for as long as you need it.

A refused origin also gets no cross-origin header, so the browser blocks the response and the console shows a cross-origin error. The request itself is still refused, so nothing is recorded. A blocked origin is the same as a blocked request, so the report simply stays empty. There is no entry in the report for a refused request.

Public ingestion is rate limited per website and per client address. When the limit is reached the endpoint answers with the code rate_limited and a Retry-After header. The script keeps a bounded number of events and retries later, so a short burst is usually not visible in the report.

The monthly limit of the plan is separate. It is metered on the events the server accepted, and the current usage is shown on the account overview.

Open the website in a normal browser window, open the console and send one event by hand:

The event appears in the report within a few minutes, in the event breakdown and in the totals for the current day. If it does not, the request never reached the server. Open the network tab and look for the request to /api/collect: a 403 means the origin was refused, a 429 means the rate limit was reached, and no request at all means the script is not installed on the page you are looking at.

The Developers page of a website shows the ingestion state next to the snippet: the time of the last event the server received, whether the tracking id is correct, and the key details of the API keys of that website.

• A recent timestamp means the script is installed on a page that people visit.
• A stale timestamp with a working script usually means the traffic is excluded, the origin is refused, or the events are being filtered.
• A test event that is missing while pageviews are present means the event name or the properties were rejected by the validation rules.