Rate limiting

Rate limits cap how many exception events PostHog ingests, so a single noisy client or runaway issue can't blow through your quota – or your bill. Exceptions received above the configured rate are dropped at ingestion, before they're stored or billed.

How rate limiting works

PostHog applies rate limits using a token bucket. You set a maximum number of exceptions and a time window (for example, 10,000 exceptions per hour). The bucket holds up to that maximum and refills steadily across the window, so short bursts are absorbed while sustained over-the-limit volume is capped. Exceptions that arrive when the bucket is empty are dropped at ingestion.

Because dropped exceptions are never ingested, they don't count toward your bill.

There are two types of rate limit. They're applied independently, and you can use either or both. You can configure both in the Error Tracking configuration page.

Project-wide rate limit

This limit applies across your entire project, regardless of which issue an exception belongs to. It acts as a single safety cap on total exception volume.

Per-issue rate limit

You set a single limit, and PostHog automatically applies it to every issue individually – each issue gets its own bucket. Once an issue exceeds the configured rate, further exceptions for that issue are dropped, while exceptions from your other issues keep flowing. Use this to stop a single noisy issue from drowning out everything else.

When configuring a per-issue limit, you can pick an issue from your most active issues to preview its recent exception volume against the limit, so you can choose a threshold before saving.

Configuring rate limits

The following options are available for each limit: