Per-issue event cap: drop after N occurrences, keep counting

Sentry's rate limits operate at the project level and drop events entirely — including their contribution to an issue's occurrence count. There's no way to cap event storage for a specific noisy issue while still knowing its true occurrence frequency.

Current behavior

• Rate limits (per-project, per-DSN) are enforced in Relay before event grouping occurs.
• Issue fingerprinting/grouping happens downstream in the main processing pipeline, after Relay.
• The "Times Seen" counter on an issue is derived from stored events only; dropped events do not increment it.
• Result: you can cap volume at the project level, but you lose occurrence fidelity for the affected issues.

Gap
Noisy, well-understood errors (e.g. a known flaky third-party call) can consume large portions of quota. Teams want to stop paying for/storing the 10,000th duplicate, but still need the occurrence count to track frequency trends, set alert thresholds, and report to stakeholders.

Options

• Early fingerprinting in Relay + distributed counter — compute a lightweight fingerprint at the Relay layer, maintain a per-fingerprint counter in a fast store (e.g. Redis), and emit a count-only outcome for events above the cap. Adds stateful coordination at the hot path; feasible but complex at scale.
• Count-only event type — introduce a lightweight "occurrence ping" that increments the issue counter without triggering full event storage or processing. Requires a new ingestion path and UI changes to surface the split between stored vs. total occurrences.
• Prior art — Rollbar supports occurrence throttling where events above a threshold are discarded but counted toward the item's occurrence total.

Action taken on behalf of Michael Chai.

Start with Relay's project-level rate-limit path, then trace the downstream main processing pipeline where fingerprinting and occurrence counts are derived. Compare the early-fingerprinting, count-only event, and prior-art options, and define the storage, processing, and UI changes needed to preserve total occurrence counts while capping stored events.