Events are being dropped

Some events arrive and some do not. Four causes, and being over your event limit is not one of them.

It is not your quota

We never drop an event for quota. At or over your monthly limit, collection continues exactly as before — no sampling, no dropping, no blackout.

That is structural rather than a promise: the code that counts your usage runs after the event has already been stored, and cannot reject it. See When you reach your event limit.

So if events are going missing, it is one of the four below.

1. A validation failure — custom events

The most common cause by a wide margin, and it only affects custom events. Page views are not affected.

An event whose name or parameters break the rules is rejected entirely. Not truncated, not corrected — dropped. The response is 400 with {"error":"invalid_payload"}.

The rules, exactly:

A capital letter is the usual culprit. Signup is rejected; signup is not. It is not folded to lowercase for you — silently correcting it would put a name in your dashboard that you did not write, and you would never learn the name was wrong.

How to find out which event. The script logs a console error naming the offending goal before it sends. That message is the only place you can learn which one — the server's response is a fixed string with no field names in it, deliberately.

If you set data-disable-console="true", you have turned that message off. Remove it while debugging.

See Tracking custom events.

2. Parameters vanishing but the event arriving

Different failure, and it looks confusing: the goal fires and shows up with no parameters attached.

All your parameters together must serialize under 2,048 bytes. Ten parameters at 255 characters each is 2,550 characters before you count the names — so an event respecting every individual limit can still exceed the total.

When it does, the event is kept and the parameters are dropped. That is the better failure: the click really happened and the count should reflect it. The script warns in the console when it is about to send an oversized set.

Fix: send less. Usually that means dropping an identifier you can already look up on your own side.

3. An exclusion you forgot about

An excluded page view returns 202 and is deliberately not stored. In the Network tab it looks identical to success.

Check, in order:

• Site settings → excluded paths. Remember /admin/* does not cover /admin, and that * is the only wildcard.

• Site settings → excluded IPs, against your current address.

• The browser flag: localStorage.truestat_ignore in the console. Anything other than undefined means this browser is excluded.

See My own visits are being counted.

4. Rate limiting — 429

The collector accepts 600 requests per minute, per site. Over that, requests are refused with 429 and {"error":"rate_limited"}, and a Retry-After header.

This is very unlikely to be you. 600 a minute is around 25 million events a month, past the top of the traffic ladder. If you are hitting it, the cause is almost always one of:

• A double install. Two tags on one page doubles every request. See Duplicate events.

• A loop. A component remounting on every render, or an event bound inside a render, can fire hundreds of times a second.

• Scroll tracking on a page that re-observes. Each element should fire once per page visit; if you see far more, something is re-initialising.

Fix the source rather than asking for a higher limit. A script sending 600 events a minute from one page is a bug, and your event quota is being consumed by it.

5. A transient failure — 5xx

503 or 500 with {"error":"temporarily_unavailable"} means a problem on our side. The script does not retry, so that event is lost.

That is deliberate: a tracker that queues and retries would eventually flood you with a stale backlog, and a lost page view is a smaller harm than a self-inflicted burst.

Check status.truestat.io. If there is nothing there and you are seeing it repeatedly, tell support@truestat.io.

Diagnosing which

Load a page, trigger the event, and watch the Network tab.