# Ingestion warnings - Docs

Sometimes PostHog runs into problems during ingestion due to incorrect or suboptimal usage of PostHog. For example, if you capture an event with a generic ID like `null`, PostHog doesn't ingest it.

If this happens, we do our best to still ingest the event and we log an ingestion warning.

![Ingestion warnings](https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/features/data-management/warnings-light-mode.png)![Ingestion warnings](https://res.cloudinary.com/dmukukwp6/image/upload/posthog.com/contents/images/features/data-management/warnings-dark-mode.png)

**Note:** These warnings are sampled. The actual number of events affected may exceed the total displayed.

List of ingestion warnings:

-   [Refused to merge with an illegal distinct ID](#refused-to-merge-with-an-illegal-distinct-id)
-   [Refused to merge an already identified user](#refused-to-merge-an-already-identified-user)
-   [Refused to process event with invalid UUID](#refused-to-process-event-with-invalid-uuid)
-   [Ignored an invalid timestamp, event was still ingested](#ignored-an-invalid-timestamp-event-was-still-ingested)
-   [An event was sent more than 23 hours in the future](#an-event-was-sent-more-than-23-hours-in-the-future)
-   [Discarded event exceeding 1MB limit](#discarded-event-exceeding-1mb-limit)
-   [Event ingestion has overflowed capacity](#event-ingestion-has-overflowed-capacity)
-   [Replay event timestamp is invalid](#replay-event-timestamp-is-invalid)
-   [Replay event timestamp was too far in the future](#replay-event-timestamp-was-too-far-in-the-future)
-   [$set or $set\_once is ignored on exception events and should not be sent](#set-or-set_once-is-ignored-on-exception-events-and-should-not-be-sent)

## Refused to merge with an illegal distinct ID

See our [identify docs](/docs/product-analytics/identify.md) for what happens when you call `identify` or `alias` with an illegal distinct ID like `guest` or `null`.

## Refused to merge an already identified user

See our [identify docs](/docs/product-analytics/identify.md#how-to-handle-duplicates-of-the-same-user) for details on how we handle duplicate users.

## Refused to process event with invalid UUID

PostHog drops events with invalid UUIDs.

There are very few cases where it would be good to provide an event UUID. PostHog generates these for you.

When generating UUIDs, there are many gotchas to be aware of. For example, deduping based on event UUID is not guaranteed due to how merges work in [ClickHouse](/docs/how-posthog-works/clickhouse.md).

## Ignored an invalid timestamp, event was still ingested

When capturing events, the `timestamp` and `sent_at` fields should be in `ISO 8601` format. When parsing fails, PostHog ignores these fields and [computes them itself](/docs/data/timestamps.md) as if omitted. These events are still ingested, but their timestamp might be different than the one you intended.

## An event was sent more than 23 hours in the future

This warning indicates a bug in your instrumentation, as we don't expect events from the future. Read about [how we compute event timestamps](/docs/data/timestamps.md) and review your instrumentation code (the `sent_at` or the `offset` values might be wrong).

These events are ingested and stored, but will not show up in the UI. If these events create new persons, these persons will have a "first seen" property in the future.

## Discarded event exceeding 1MB limit

PostHog discards events exceeding 1 megabyte in size after processing. The two common ways this happens are:

1.  An event is captured with an exceptionally large number of properties (including person properties)

2.  One or more installed apps transformed the event and enriched it with a large amount of additional property data.

## Event ingestion has overflowed capacity

This warning indicates PostHog is receiving more events for a single `distinct_id` than it can process in the main [ingestion pipeline](/docs/how-posthog-works/ingestion-pipeline.md). These events are still safe and ingested but through a slower overflow pipeline. This is often a sign of an instrumentation bug such as a loop sending the same event.

## Replay event timestamp is invalid

The replay event timestamp is not valid and the session replay event is dropped.

## Replay event timestamp was too far in the future

The replay event timestamp is more than 7 days in the future and the session replay event is dropped.

## Invalid set operations on exception events

The `$set` or `$set_once` properties are ignored on exception events and should not be sent.

### Community questions

Ask a question

### Was this page useful?

HelpfulCould be better