Sentry charges by event volume, not by seat. Understanding what counts as an event, how spike protection works, and when overages kick in is essential to budgeting accurately.
Sentry has four event types, each with its own monthly quota and pricing:
Any exception or error event captured by your Sentry SDK. Each occurrence of an error counts — even if it's the same exception thrown thousands of times. You can reduce error counts by enabling grouping and deduplication, but each event still counts when ingested.
A performance transaction is a distributed trace — typically a single HTTP request, database query session, or background task — including all the spans within it. The transaction itself is one event; spans inside it are not counted separately.
A session replay is a video-like recording of a user's browser session, capturing mouse movements, clicks, network requests, and console errors. Each replay of a distinct user session counts as one event. Replays are useful for debugging complex UI issues.
Continuous profiling samples your application's call stack at regular intervals, creating flame graphs of CPU usage. Profiling events are counted separately from performance transactions. Currently available for Python, Node.js, Java, Go, and Rust.
Spike protection is one of Sentry's most important features for production safety. Available on Team plans and above.
A deploy with a critical bug triggers 50,000 errors in 2 hours, exhausting your entire monthly 5,000 quota in minutes. Sentry stops ingesting events. You're blind for the rest of the month.
The same deploy spike is detected. Sentry samples events during the spike at a reduced rate — you still see the error, its stack trace, and frequency. Your quota is preserved for the rest of the month.
Most teams don't need 100% trace coverage. 10-20% sampling gives statistically representative performance data at 80-90% cost savings. Set tracesSampleRate: 0.1 in your SDK config.
Use beforeSend in your SDK config to drop known-harmless errors (404s from bots, cancelled fetch requests, third-party script errors). These count toward your quota but have no debugging value.
Sentry's dashboard has built-in filters: browser extensions, localhost, known crawlers. Enable these in Project Settings → Inbound Filters. Free error reduction with one click.
Use fingerprinting rules to group related errors into fewer issues. This doesn't reduce ingested events, but helps you prioritise which errors to fix first — reducing future volume.
Every integration you connect can generate automatic events. Review which integrations are active and whether they're generating noise. Disable noisy integrations during off-hours.
Sentry counts four main event types: (1) Errors — any exception or error captured by the Sentry SDK. Multiple occurrences of the same error count separately. (2) Performance transactions — a trace of a user request or background job, including all spans within it. (3) Session replays — video-like recordings of user browser sessions. (4) Profiles — continuous profiling calls sampling your application's call stack. Each plan includes monthly quotas for each type.
Spike protection is a safeguard that prevents a sudden burst of errors from exhausting your entire monthly quota. When Sentry detects an abnormal spike (typically 4x or more above your recent baseline), it temporarily throttles event ingestion — dropping some events during the spike — rather than consuming your full quota in minutes. This means a bad deploy doesn't blind you for the rest of the month. Spike protection is available on Team plans and above; the free Developer plan does not have it.
Reserved volume is purchased in advance at a discounted rate and committed for the billing period. On-demand volume is charged after the fact at a higher per-event rate when your reserved volume is exhausted. For predictable workloads, reserved volume is almost always cheaper. On-demand gives flexibility but can result in unexpected charges. Sentry lets you set on-demand spending caps to prevent surprises.
Key cost reduction strategies: (1) Use sampling — send only a percentage of performance transactions rather than 100%. 10% sampling on 1M transactions gives representative data at 10% of the cost. (2) Implement error filtering in your SDK configuration to ignore known noise (like expected 404s). (3) Set up inbound data filters in Sentry's settings to drop events from known bot traffic. (4) Use issue grouping rules to aggregate similar errors and reduce unique event counts. (5) Review your performance trace sample rate — most teams can safely sample at 10-20%.