If you're sending epoch timestamps to PostHog, your event data might not be appearing when you expect. PostHog treats these as current ingestion times, not historical event times.
Hey WondTech readers! Ever wonder why your historical event data in PostHog looks like a sudden spike today, instead of a smooth curve over time? Well, we've got an important heads-up for anyone using PostHog's Capture API. It turns out that if you're sending event timestamps using the common 'epoch' number format, PostHog isn't recording them at their actual historical time.
Here's the scoop: Imagine you're backfilling six months of user sign-up events into PostHog. You send them through the API, and everything looks good – you even get a 200 OK response. But when you check your insights, you see a huge spike of sign-ups *today*, rather than seeing those events spread out across the past half-year. The events aren't missing; they're just getting stamped with the time PostHog *received* them, not the time they actually happened.
The issue boils down to how PostHog expects timestamps. Their documentation clearly states they need the ISO 8601 format, like '2026-07-26T06:00:00Z'. An epoch number – that long string of digits representing seconds or milliseconds since 1970 – is a different animal. While PostHog's API *accepts* the request with an epoch timestamp and returns a 200, it doesn't apply your historical value. Instead, it logs the event at the moment it was ingested.
So, what's the fix? Simple: make sure your `timestamp` field is always in ISO 8601 format before you send it to PostHog. Tools like Pixellint can even help catch these errors before they cause data headaches. This is similar to how Segment's HTTP API works, which also uses ISO 8601. Just be careful if you're also working with Amplitude, as they specifically prefer milliseconds since epoch. Don't mix and match formats for different platforms!
One more quick tip: PostHog also requires a `distinct_id` for every event. If it's missing or empty, the event won't be ingested, even if the API still gives you a 200 OK. The takeaway here is to always double-check your data format and required fields, because an 'OK' status isn't always the full story. Keep your analytics clean and accurate!
Here's the scoop: Imagine you're backfilling six months of user sign-up events into PostHog. You send them through the API, and everything looks good – you even get a 200 OK response. But when you check your insights, you see a huge spike of sign-ups *today*, rather than seeing those events spread out across the past half-year. The events aren't missing; they're just getting stamped with the time PostHog *received* them, not the time they actually happened.
The issue boils down to how PostHog expects timestamps. Their documentation clearly states they need the ISO 8601 format, like '2026-07-26T06:00:00Z'. An epoch number – that long string of digits representing seconds or milliseconds since 1970 – is a different animal. While PostHog's API *accepts* the request with an epoch timestamp and returns a 200, it doesn't apply your historical value. Instead, it logs the event at the moment it was ingested.
So, what's the fix? Simple: make sure your `timestamp` field is always in ISO 8601 format before you send it to PostHog. Tools like Pixellint can even help catch these errors before they cause data headaches. This is similar to how Segment's HTTP API works, which also uses ISO 8601. Just be careful if you're also working with Amplitude, as they specifically prefer milliseconds since epoch. Don't mix and match formats for different platforms!
One more quick tip: PostHog also requires a `distinct_id` for every event. If it's missing or empty, the event won't be ingested, even if the API still gives you a 200 OK. The takeaway here is to always double-check your data format and required fields, because an 'OK' status isn't always the full story. Keep your analytics clean and accurate!
