TraceLog is rejecting events

Last updated Oct 25, 2026

Events sent for this project are reaching TraceLog and coming back refused, each with its reason. Read the reason to find what to correct in the request.

What was observed

TraceLog refused events sent for this project for a reason in what the installation sends, or the code in the verification tab reported that TraceLog rejected its requests. Where TraceLog recorded the refusal, this diagnostic says its reason, so you can see which part of the request was wrong; a rejection only the verification tab reported comes with no reason.

TraceLog is rejecting events from this site.

The reasons TraceLog gives

Reason	What it means
`invalid_schema`	A field is missing, misspelled, or the wrong type
`unknown_version`	The envelope version is one this API does not know
`too_large`	The batch exceeded 256 KB, or carried more than 50 events
`future_time`	An event's `occurredAt` was more than five minutes ahead of the server's clock; it never shows as this diagnostic
`expired`	The event happened more than 30 days ago, and its day's figures are closed; it never shows as this diagnostic

Events more than seven days old are accepted and marked as late. An event from more than 30 days ago arrives after its day's figures have closed: it is refused on its own, as expired, and the rest of its batch is stored.

What to check

On Installation and keys or Path, this diagnostic says what TraceLog is rejecting and what to correct — which part of the request was refused, and how to send it.
invalid_schema on a server-side call is usually the event name form (lowercase, starting with a letter), occurredAt without millisecond precision, or an eventId or sessionId that is not a UUID v7. A context over 8 KB serialised is invalid_schema too.
future_time means the sending machine's clock is ahead. It appears in the server API's response and in Path's technical detail, not in this diagnostic: a visitor's device clock is nothing the site can correct.
too_large means the batch itself was over 256 KB or held more than 50 events: send smaller batches.
expired appears in the server API's response and in Path's technical detail, not in this diagnostic. Something held the event for over a month before sending it — a replay, or a queue that waited that long. Nothing to fix in the installation; send recent events.

Effect on verification

It reports. Refused events are not stored, so they cannot count towards verification.