Setting the file. One moment.
Skill 104 · Resolving Ingestion Warnings
Subchapter 104.8
references/fixing-ignored-invalid-timestamp.mdMarkdown2 KBView on GitHub
An event’s timestamp property couldn’t be parsed, so PostHog ingested the event with the server’s arrival time instead of the intended one.
Category event, severity warning: no event was lost, but its time is wrong — which quietly corrupts trends, funnels with time windows, and historical imports (everything lands at import time).
Note this is strictly about unparseable timestamps. Events that arrive late with valid timestamps (mobile SDKs flushing offline queues, batched backends) are handled normally and don’t produce this warning.
The timestamp string isn’t a format PostHog can parse. Common sources:
"07/08/2026 14:32", "8 Jul 2026",Date objects serialized via string concatenation instead of .toISOString(),posthog:execute-sql: SELECT timestamp, details FROM system.ingestion_warnings WHERE type = 'ignored_invalid_timestamp' AND timestamp > now() - INTERVAL 7 DAY ORDER BY timestamp DESC LIMIT 20. The details JSON carries the offending value and a reason from the parser — usually self-explanatory.timestamp is set on capture calls (custom timestamps are most common in backend SDKs and migration/import scripts).Send ISO 8601 with timezone:
client.capture({
distinctId,
event: 'order shipped',
timestamp: new Date(order.shippedAt).toISOString(), // '2026-07-08T14:32:00.000Z'
})If you don’t need a custom time, omit timestamp entirely — the SDK stamps it correctly. For historical imports, validate the conversion on a sample before running the batch: mis-parsed rows are ingested at “now” and cannot be re-dated afterwards.
Re-run the flow or a sample of the import, re-query system.ingestion_warnings with posthog:execute-sql (filter type = 'ignored_invalid_timestamp', timestamp after your fix) — no new occurrences — and confirm new events carry the intended times.