How to model your Sentry bill (events, spans, replays, logs).

Why a model beats a snapshot

Search for “how much does Sentry cost” and you will find answers from 2022, 2023, and 2024 that contradict each other. They are all correct for when they were written. Sentry has changed its plan structure, renamed tiers, bundled and unbundled add-ons, and adjusted per-unit quotas multiple times in the past four years. The most significant recent change was in August 2025, when the included span quota on Team and Business plans dropped from 10 million to 5 million per month, doubling the effective per-span cost for any team that was close to the old floor.

A snapshot gives you a number. A model gives you a formula. The formula survives the next pricing change because you can update the price inputs without rebuilding the structure. More practically: the formula is also the thing that answers “what happens to the bill if we add a new service?” or “how much do we save if we cut replay sampling from 10% to 2%?”

The model is also the thing you bring to the budget conversation. A number without a derivation is easy to dismiss. A spreadsheet that shows which line item is driving the bill, what the current trend is, and what it would look like at 2x traffic is harder to argue with.

The five line items in 2026

Sentry bills five categories on the current Team and Business plans. Each has a different unit, a different included quota, and a different overage mechanism. Getting the structure right before pulling numbers saves a lot of confusion.

Errors (events)

The original Sentry line item. An error event is one exception or unhandled rejection captured and sent to Sentry. The unit is events per month. Sentry counts each unique envelope payload that reaches the ingest endpoint and is not dropped by Relay filtering. Rate-limited events that Relay drops server-side do not count against quota.

Team plan included: 50,000 errors/month as of mid-2026. Overage is billed per block of additional errors. The exact block size and price are on the billing page; treat any number quoted here as a starting point to verify against your plan.

Performance (spans)

Spans are the unit of distributed tracing. Every traced function call, database query, HTTP request, or custom instrumentation block generates one span. A single user request in a moderately-instrumented web app might generate 20–80 spans depending on how many integrations are active.

This is the line item where most teams underestimate volume. A service handling 100 requests per second with an average of 40 spans per transaction generates 240 million spans per day. At 5 million included per month, that team is generating 48x their included quota before overages apply. The August 2025 quota reduction from 10M to 5M made this gap much more visible.

Replays

Session replay captures and reconstructs user sessions in the browser. Each session is one replay. The volume depends on your replaysSessionSampleRate and replaysOnErrorSampleRate settings, multiplied by your MAU. A product with 500,000 monthly active users and 10% session sampling generates roughly 50,000 replays per month. Replays include the DOM mutations, console events, and network requests from the session.

Logs

Sentry added structured log ingestion in 2024. Logs are billed per log line ingested. The volume is bounded only by how much your application logs. A production service with verbose structured logging can generate tens of millions of log lines per month. This line item is the most dangerous to leave unmonitored because log volume scales with debug verbosity, not with user traffic.

Profiles

Continuous and transaction profiling generate profile samples. Transaction profiling captures a profile alongside each traced transaction; continuous profiling runs independently of traces. Volume scales with either transaction rate or profiling duration. Most teams at the Team plan tier use profiling sparingly because the signal density is high and the included quota is modest.

Per-item meter and unit

How errors are counted

Sentry counts an error event when the SDK sends an envelope containing an exception or message event and Relay accepts it. Relay can be configured to drop events before they reach the quota counter: rate limiting at the DSN level, inbound data filters (browser extensions, localhost events), and the sampleRate setting in the SDK all reduce the count before ingest. Ignored issues still count against quota; ignoring an issue suppresses alerting, not ingestion. The distinction matters for the model.

How spans are counted

Every span in every accepted trace counts. The SDK generates spans automatically for HTTP requests, database queries, and framework-specific operations, and your instrumentation adds more. The span count per transaction is highly dependent on which auto-instrumentation packages are active. A Django app with the Sentry Django integration, SQLAlchemy integration, and Redis integration enabled will generate substantially more spans per request than the same app with only the base SDK.

Sentry samples at the trace level: traces_sample_rate determines the fraction of transactions that generate a complete trace and all its spans. If you set traces_sample_rate to 0.1, you are sending 10% of transactions, and 10% of the span volume those transactions would generate. Spans from unsampled transactions are dropped client-side and never reach the quota counter.

How replays are counted

The Sentry browser SDK creates a replay session when the page loads (if session sampling fires) or when an error occurs (if error sampling fires). One page load or one error session equals one replay. Replays are compressed before transmission; the billing unit is sessions, not bytes.

How logs are counted

Each log line sent to Sentry’s log ingestion endpoint is one unit. The SDK batches lines but each line counts individually. Log volume is highly dependent on your logging configuration. If you send DEBUG-level logs in production, you will generate orders of magnitude more volume than if you filter to WARNING and above before sending.

Pulling your actual numbers

You need three months of historical data to build a useful model. One month is not enough to see seasonality; twelve months is more than you need for the initial version. Three months shows the trend and the floor.

There are three places to pull the data:

Settings > Usage & Stats

The Sentry UI shows a breakdown by category for the current billing period and recent history. This is the fastest starting point. Navigate to Settings, then Usage & Stats. You will see a chart and a table with the count for each category. Export the table if you can; otherwise transcribe the monthly totals for the past three months.

One limitation: the UI shows org-level totals. If you want per-project breakdowns, you need the API.

The organization stats API

The /api/0/organizations/{org_slug}/stats_v2/ endpoint returns daily usage by category. It accepts a date range, a granularity, and a field filter. A call with category filtering returns the exact data underlying the billing UI, at daily resolution, for any date range within your retention window.

curl -H "Authorization: Bearer $SENTRY_TOKEN" \
  "https://sentry.io/api/0/organizations/YOUR-ORG/stats_v2/?
  field=sum(quantity)
  &groupBy=category
  &start=2026-03-01T00:00:00
  &end=2026-05-31T23:59:59
  &interval=1d"

The response shape is a time series with a group per category. Parse the totals field for monthly aggregates. This is the authoritative source for your model inputs.

Billing CSV

Settings > Billing > Usage & Payments has a CSV export. It shows the invoice line items, the included quota, the overage units, and the overage charge for each billing period. This is the best source for understanding what Sentry actually billed you, including the per-unit prices that applied. Cross-reference it against the API data to confirm your numbers.

Building the spreadsheet

The model is a table. Rows are months. Columns are the five line items plus derived columns for bill calculation. Here is the structure:

The overage formula is the critical one. Sentry sells overages in blocks, not at a per-unit rate. A block of 100,000 errors costs a fixed amount; if you use 50,001, you pay for the full block of 100,001–200,000. Model this with ceiling division: CEILING(MAX(0, actual - included) / block_size) * block_price. Using a simple linear rate instead will underestimate overages.

Fill three months of historical data into the usage columns. Verify the total modeled bill against the actual invoice from your billing CSV. If they match within 5%, your model is accurate. If they do not, the most common source of discrepancy is a secondary plan add-on (reserved capacity, seat-based charges) that is not in your model yet.

Sensitivity: what moves the bill most

Once the model matches history, add a sensitivity section. This is a separate small table with inputs for traffic multipliers and outputs for bill changes. The structure is:

• Input: traffic multiplier (1x, 2x, 5x, 10x)
• Derived: each line-item volume at that multiplier (assume linear scaling)
• Output: modeled bill at each multiplier

For most teams, the answer is: spans move the bill the most, and the relationship is nonlinear because of overage blocks. A 2x traffic increase doubles span count. If your span count is already 3x the included quota, doubling it moves you further up the overage curve. The bill might go up 4x even as traffic only went 2x.

Errors are less sensitive to traffic multipliers because bugs do not scale linearly with requests. A 10x traffic increase might produce a 2x or 3x increase in errors, not 10x, because most of the new requests succeed. The exception is error-heavy deploys: a bad release that throws on every page load will produce a linear or superlinear relationship between traffic and errors until the error rate is addressed.

Logs are the most dangerous line item for bill sensitivity because log verbosity is often orthogonal to traffic. A DEBUG log statement that fires on every function call in a hot path generates the same volume at 1x traffic as 10x traffic because the log fires on framework internals, not user requests. Audit your highest-volume log sources before they appear in an overage charge.

Sampling levers and what they cost in signal

Every Sentry line item has at least one lever that reduces volume. Here is what each lever does to the model and what it costs in signal quality.

traces_sample_rate

Setting traces_sample_rate to 0.1 sends 10% of transactions. Span volume drops roughly proportionally. At 0.1, you see 10% of transactions and 0% of the unsampled 90%. You will miss the slow query that only happens in 1 in 20 requests. Tail-latency debugging becomes harder, because the slow cases are underrepresented relative to their frequency.

The right value depends on your transaction volume. A service handling 10 requests per second with 40 spans each generates 34 million spans per day. At 0.01 sample rate, that is 340,000 spans per day, or roughly 10 million per month. That still exceeds the 5 million included quota, but sits in a manageable overage band.

Head-based sampling is blunt. If you care about p99 latency, Sentry supports dynamic sampling rules that increase sample rate for slow transactions or error transactions. Use those before cutting the global rate further.

replaysSessionSampleRate and replaysOnErrorSampleRate

Session sampling controls what fraction of normal sessions generate a replay. Error sampling controls what fraction of sessions with errors generate a replay. Setting session rate to 0 and error rate to 1.0 is a common configuration for teams that want replay only on error sessions. For a service with 500,000 MAU and a 0.5% error rate, that configuration generates roughly 2,500 replays per month instead of 50,000. The signal cost is no coverage of user behavior in happy-path flows.

Log level filtering

The most effective lever for log volume is filtering before sending. Set a minimum severity level in your SDK or in Relay’s inbound filter configuration. Filtering to WARNING and above typically cuts log volume by 90–99% for production services. The signal cost is losing DEBUG and INFO context for debugging.

A better approach: filter to INFO in production, keep DEBUG in staging. That way you have the structured context for debugging in an environment where you can reproduce issues.

profilesSampleRate

Transaction profiling adds one profile per sampled transaction. At traces_sample_rate=0.1 and profilesSampleRate=1.0, you profile 10% of transactions. Cutting profilesSampleRate to 0.1 brings you to 1% of transactions profiled. The signal cost is thinner profiling data; finding a specific hot function becomes harder with fewer samples.

The overage trap

Most bill shock on Sentry does not come from the base plan cost. It comes from overages, and overages have a structural quirk that makes them expensive in ways that are not visible until the invoice arrives.

Overages are charged in blocks. If your included error quota is 50,000 and your actual usage is 51,000, you pay for the next full block of errors, not for one thousand errors. The block structure means the effective per-unit cost in the first overage block is high, because you pay for the whole block even if you use a fraction of it.

The second structural issue is that overages are not visible in real time unless you have set up usage alerts. Sentry does have a usage alerts feature: Settings > Alerts > New Alert > Metric Alert, category = errors/spans/etc. Set an alert at 80% of your included quota so you have time to react before the overage starts.

The third issue is that overages are per billing period, not per month in the calendar sense. If your billing period starts on the 15th and you have a traffic spike on the 10th, you are accruing overages against the current period while looking at last period’s numbers in the UI. The stats API’s date range parameter accepts the exact start date of your billing period.

When the model says self-host

The break-even calculation is the final sheet in your model. The inputs are your modeled annual Sentry cost and the estimated annual cost of a self-hosted alternative. The self-hosted cost has two components: infrastructure and ops time.

Infrastructure for a single-binary alternative like urgentry on a $40/month VPS (4 vCPU, 8 GB RAM, 160 GB SSD) runs roughly $480/year. Add $60/year for backup storage. Infrastructure cost is around $540/year.

Ops time is harder to estimate and is where most self-hosting calculations go wrong. Initial setup for a production-ready deployment (TLS, backups, alerting, monitoring) takes 4–8 hours for an engineer who has done it before. Ongoing maintenance — upgrades, incident response for the tracker itself, storage management — runs roughly 2–4 hours per month for a small deployment. At $150/hour all-in cost, that is $300–600/month in ops time, or $3,600–7,200/year.

The math only favors self-hosting when the Sentry bill exceeds the ops time cost significantly enough to justify the operational risk. For a team with a $500/year Sentry bill and no dedicated ops capacity, self-hosting is almost certainly wrong. For a team with a $15,000/year Sentry bill and an engineer who already manages infrastructure, the calculation is straightforward.

The break-even is not just volume; it is traffic shape. A team with high span volume and low error volume pays more per unit of observability on Sentry than a team with the inverse shape, because spans overage faster. A team with predictable, flat traffic has a simpler ops story for self-hosted than a team with large spikes that require adaptive capacity.

Staying on Sentry is the correct answer when: your team has no spare ops capacity, your Sentry bill is under $3,000/year, or you need product surfaces (full session replay, advanced performance queries, the Discover UI) that a simpler alternative does not match. Be honest about what you actually use. Most teams who move off Sentry find they were paying for three or four features they used daily and twenty features they had never opened.

A worked example

The numbers below are anonymized from a composite of real billing CSVs. Call the company Meridian: a Series B SaaS, 500,000 monthly active users, web app with React frontend plus three backend services (Python API, Go worker, Go ingest service). Business plan.

Their actual monthly numbers (Q1 2026 average)

Meridian was on Business plan at $80/month base. Their error overage was roughly $45/month on top. Span overage was $310/month. Log overage was $85/month. Total monthly bill: approximately $520, or $6,240/year.

What their model showed

The span line was the clear driver. 87 million spans against a 5 million included quota meant they were paying for 82 million spans every month in overage. Their traces_sample_rate was 1.0 on all three backend services. The Go ingest service handled 280 requests per second at peak and was generating an average of 60 spans per transaction.

Sensitivity analysis: at 2x traffic (anticipated for Q3 2026 after a marketing push), span volume would reach roughly 160 million per month. Span overage would approximately double to $620/month. Total bill at 2x: around $800/month.

The levers they pulled

They set traces_sample_rate to 0.1 on the Go ingest service, which was high-frequency but low-variance (ingest services do the same thing on every request). They kept it at 1.0 on the Python API, where they needed high coverage for debugging user-facing flows, and at 0.25 on the Go worker. Net effect: span volume dropped from 87 million to roughly 22 million per month. Overage dropped from $310 to $60. Total monthly bill fell to approximately $270.

The signal cost: they can no longer investigate individual ingest service requests in traces. They deemed that acceptable for a service with low variance. They also added a dynamic sampling rule to increase the ingest service rate to 1.0 for any transaction with an error, so they retain full traces on failures.

The self-hosting question

After the sampling change, Meridian’s modeled annual bill was around $3,240. At their infrastructure cost estimate ($540/year) and ops time estimate (3 hours/month at $150/hour for an engineer who already manages their AWS stack), self-hosting would cost roughly $6,000/year in total — more than their current Sentry bill. They stayed on Sentry.

The calculation would change at 10x traffic. At 10x, their span volume at a 0.1 sample rate would be 220 million per month, putting them deep into span overages again. At that scale, the Sentry bill would likely exceed $2,000/month. That is the point where the ops time math starts to favor self-hosting, assuming their team’s ops capacity grows in proportion to the rest of the company.

Frequently asked questions