Sentry quota counting is the set of rules by which the hosted Sentry service decides whether an incoming item consumes a customer’s paid volume. Sentry describes its quota as the amount of data (errors, spans, replays, logs, application metrics and attachments) that the customer pays Sentry to track.[1] Because the commercial model is consumption-based, counting rules are the closest equivalent of a licence metric definition. They determine both the bill and the point at which monitoring stops. The Terms of Service refer to a “Scope of Use” defined as any monthly usage quota or seat allowance set out in an order, which is what these rules measure in practice.[10]
Metrics
The documentation distinguishes several data types. An event is one instance of sending data to Sentry, excluding attachments, and is generally an error or a transaction or span.[1] Data is anything sent, including events, logs, application metrics, attachments and event metadata.[1] The catalog treats each billing category as a metric: Error event, Span, Replay, Attachment (GB), Log GB and Application metric GB.
Two points are easy to miss. First, attachments are measured by size rather than by number of attachments sent.[6] Second, logs and application metrics are counted individually and are not grouped into issues, while errors and spans are grouped into issues; the issues themselves do not count towards quota, but the errors and spans that comprise them are counted.[1]
Application Metrics are described as counters, gauges and distributions sent to track application health signals, and each metric event is a single counter, gauge or distribution value together with its metadata.[1][8] The metrics documentation warns that high-cardinality custom attributes inflate metric volume.[8]
Counting: what is and is not counted
Before any evaluation, Sentry confirms that each event includes a valid DSN and project and can be parsed; for error events it also validates the fingerprint. An event failing these checks is rejected.[1] Sentry then evaluates each event against the checks below. The documentation lists them from easiest or least time-consuming to most challenging.[1]
- Spike Protection. If a spike threshold has been reached, events are dropped and do not count.
- Quota adjustment. Events and attachments that exceed the quota are not accepted.
- Rate limits. If a project-level rate limit applies, the event does not count (errors and attachments).
- Event repetition. Some repeat events count and some do not (see below).
- Inbound filters. An event matching an inbound filter configured in sentry.io does not count.
- SDK controls. Sample rates, SDK filtering with callbacks such as beforeSend and SDK configuration decide whether the event is sent at all.
- Size limits. Events exceeding Sentry’s size limits are not accepted, which can affect the attachments quota.
The usage statistics page breaks data into three categories, accepted, dropped and filtered, and only accepted data affects the quota.[3] The Usage Stats tab shows up to 90 days of data for the whole organization, by project, and is visible to all organization members.[3] For span usage the page notes that the Usage Stats tab is visible only on Team, Business or Enterprise plans.[4]
Event repetition
Repeat errors are treated differently depending on how the issue was handled.[3]
- A new error event for a previously resolved issue counts toward quota because it may represent a regression.
- A repeat event for an issue with ignored alerts counts because the event is still occurring.
- A repeat event for an issue set to Delete and Discard does not count.
Delete and Discard is available only on Business and Enterprise plans.[3]
Inbound filters
Inbound filters are server-side and applied before rate limits are checked. The documented filters for errors include common browser extension errors, events from localhost, known legacy browser errors, known web crawlers, error messages, specific release versions and certain IP addresses.[3] Filtering by release is available only on Business or Enterprise plans.[4] Setting filters on error events indirectly filters their attachments, because attachments cannot be filtered directly.[6] Logs and application metrics can also be filtered in sentry.io; the filtered items do not count even though they have still been sent.[7][8]
Rate limits
Rate limiting sets the maximum number of error events that a project key (DSN) accepts during a period, for example 500 events per minute. A project can have several keys with different or no limits.[3] The feature is available only on Business or Enterprise plans.[3] Events dropped because of a rate limit generate a 429 error code, and limited events do not count toward quota.[3][1] Attachments have an organization-level setting for the number of stored crash reports per issue.[6]
Spike Protection
Spike Protection is Sentry’s mechanism for preventing a short burst from using the monthly quota. It currently applies to errors, transactions or spans, and attachments.[2] It is enabled per project by team members with Manager, Billing or Owner-level permissions, from Settings > Spike Protection.[2] Existing users with the older organization-level setting were switched to per-project protection with all projects enabled by default.[2]
How a spike is detected, as documented:
- Sentry sets a threshold for each project and, when it is reached, applies a dynamic rate limit and begins discarding events.[2]
- The threshold is the higher of two calculations. One is a minimum number of events derived from the quota. The other is a weighted projection of usage over the last 168 hours (7 days), allowing for daily and hourly seasonality.[2]
- Thresholds are recalculated every hour for the duration of the spike. Protection deactivates when the spike passes.[2]
- The minimum event calculation takes the greater of one tenth of the minimum reserved volume on the Developer plan for that event type or a formula of (3 x quota) divided by (720 x number of projects), with the project count capped at 5.[2]
- If volume stays high for a sustained period it becomes the new baseline, and the customer may still run through its quota quickly.[2]
Spike Protection does not apply during trials, because category quotas are unlimited for the duration of the trial.[2] Enabling Spike Protection does not automatically enable notifications; a notification action must be added, which can be a personal Sentry notification to eligible Owner, Manager and Billing members or a Slack, PagerDuty or Opsgenie action.[2] Dropped events can be reviewed in the Usage Stats tab, and shorter spikes appear in the Audit Log.[2]
Quota exhaustion and adjustment
When the quota threshold is exceeded, the server responds with HTTP status 429 and a Retry-After header. Clients are expected to drop events until the limit expires rather than retry them. Because ingestion and rate limiting are asynchronous, the 429 is always slightly delayed.[3] Data sent after reserved volume and the pay-as-you-go budget are used up is dropped and not charged.[9] Owners receive notification emails when volume approaches or exceeds quota, and only Billing or Owner members can change quotas.[3] On a paid plan the first time the errors quota is exceeded the organization is entered into a one-time grace period.[3] See First-time quota grace period.
The Terms of Service allow Sentry to suspend access where a customer’s actions risk harm to others or to the Service, including by regularly exceeding applicable rate limits, or where an account is 30 days or more overdue.[10]
Practical points for asset managers
- The meaningful compliance measurement is Sentry’s Usage Stats for each organization and category, not an installed-base count. The customer cannot be “over-deployed” in the traditional sense, because excess data is dropped or charged within the PAYG ceiling the customer chose.[9]
- Differences in plan unlock controls: Business or Enterprise is needed for rate limiting, release filters and Delete and Discard.[3]
- SDK sampling and filtering are the customer’s main levers. SDK sample rates and beforeSend callbacks reduce the volume sent, while spans are reduced by sampling transactions.[1]
- Trials bypass quota and Spike Protection, so an organization on trial can look unusually high-volume in historical data.[2]
Out of scope
Prices for each category are in Sentry plans, reserved volume and pay-as-you-go. Monitors, profile hours and Seer have their own counting rules, covered in Sentry Seer, profiling, monitors and usage-priced products.