> For the complete documentation index, see [llms.txt](https://developer.paddle.com/llms.txt).

# Usage event timestamp is too far in the future

A usage event's `occurred_at` can't be more than 24 hours after the current time.

> **Early access (beta): usage-based billing**

---

## Example

```json
{
  "error": {
    "type": "request_error",
    "code": "usage_event_future_timestamp",
    "detail": "usage event occurred_at 2026-08-07T12:00:00Z is more than 24 hours in the future",
    "documentation_url": "https://developer.paddle.com/errors/usage-events/usage_event_future_timestamp"
  },
  "meta": {
    "request_id": "00000000-0000-0000-0000-000000000000"
  }
}
```

## Details

| Attribute | Value |
| --- | --- |
| Status code | 400 |
| Error code | `usage_event_future_timestamp` |
| Error message | usage event occurred_at %s is more than 24 hours in the future |

## Common causes

- `occurred_at` is set to a planned or scheduled time, rather than the time the usage happened.
- The code that generates `occurred_at` builds or converts the date incorrectly, like using the wrong year or swapping the day and month.
- The clock on the system that records usage is running more than 24 hours ahead.

## Common solutions

- Set `occurred_at` to the time the usage happened, as an RFC 3339 datetime string in UTC.
- Check the code that generates `occurred_at` for date formatting or conversion errors, and check that the clock on the system that records usage is correct.
- Send the event again once `occurred_at` is correct. Paddle didn't record the rejected event, so sending it again doesn't count the usage twice.