I need to upload errors or transactions with older timestamps to Sentry, and I want to know how far back those timestamps can go before Sentry adjusts or rejects them.

Errors and transactions have different backdating limits.

You can send error events with timestamps as far back as your project’s event retention period. Within that window, Sentry keeps the original timestamp.

If the timestamp is older than your event retention period, Sentry still accepts the event, sets the timestamp to ingestion time, and records a processing error with the title Invalid timestamp (too old). When the event includes both server_time and sdk_time, the UI also shows a detail line Adjusted timestamps by … with a humanized duration for the difference (for example, “a month”).

This backdating window follows event retention. It is not a separate fixed 30-day cap. For current retention by data type and plan, see the data retention periods documentation and How Long Are Errors/Events Stored in Sentry?.

Transactions can keep original timestamps only if both start and end timestamps fall within about the last 5 days. Transactions older than that are rejected and do not appear in Sentry.

That 5-day window is separate from your project’s event retention period.

For spans, logs, Session Replay, and trace metrics, Sentry rejects items whose timestamps are older than the retention window for that data type. Sentry does not shift those timestamps forward to ingestion time. Too-old items are discarded and do not appear in Sentry.

If timestamps look wrong but are recent, the cause may be device or host clock skew. See Why do I see "Clock drift detected in SDK" processing errors?.