Usage-based error monitoring pricing: how do errors vs spans vs session replay affect the bill, and how do budget caps work?

Most teams switching to usage-based monitoring hit the same question fast: what actually moves the bill—errors, spans, Session Replay—and how do you keep it inside a budget without turning off visibility? Let’s break down how Sentry’s usage-based pricing works in practice so you can size a plan, set guardrails, and avoid surprises.

Quick Answer: Sentry bills separately for major telemetry types: errors (Error Monitoring), spans (Tracing), replays (Session Replay), plus logs, monitors, and attachments. You pick base monthly quotas for each, then add optional pay-as-you-go overages with hard or soft caps so spend stays predictable even if traffic or bugs spike.

The Quick Overview

What It Is: A usage-based pricing model for Sentry where you pay for the volume of events you send: errors, spans, replays, logs, monitors, and profiling time. Each has its own quota and overage rate.
Who It Is For: Engineering teams who want to capture rich production telemetry—errors, traces, replays—without overpaying for unused capacity or getting blindsided by runaway costs.
Core Problem Solved: Traditional “all-in” observability pricing hides what’s driving cost. Sentry separates event types and lets you cap usage, so you can tune what you collect to match your debugging needs and your budget.

How It Works

Sentry’s pricing is built around a few primitives you can control independently: errors, spans, replays, logs, cron/uptime monitors, and profiling hours. You:

Pick a base plan (Team, Business, or higher) with included usage.
Configure monthly quotas for each data type (errors, spans, replays, etc.).
Optionally enable pay-as-you-go overages with budget caps and safeguards.

When your application runs, Sentry SDKs send events—error events, transaction spans, Session Replay recordings, logs, and so on. Each event type draws down the corresponding quota. If you hit the quota and have overages enabled, Sentry continues to accept data and bills extra units at the published per-unit rate. If you hit a hard cap, Sentry stops accepting that event type until the next billing cycle (or until you adjust your limits).

Under the hood, that means:

Errors are counted per error event captured (exception, crash, or manually-sent error).
Spans are counted per span in your traces (each operation inside a transaction).
Replays are counted per captured Session Replay (a “video-like” user session).
Other resources—logs, cron/uptime monitors, attachments, profiling—follow the same pattern.

From a debugging workflow perspective, you can think of each as a lever: more errors for breadth of coverage, more spans for detailed performance analysis, more replays for “show me what the user did,” then tune each based on how often you actually use them.

1. Errors: The core of usage-based error monitoring

What counts as an error?
Every time Sentry’s SDK captures a bug—an exception, crash, or your own captureException/captureMessage call—that’s one error event. Those events are:

Grouped into issues with stack traces, environment, release data, and suspect commits
Tied into alerts, Ownership Rules, and integrations (e.g., Linear, Jira)
Subject to your error quota for the month

Plans and defaults:

Free tier includes 5K errors/month
Paid plans start at 50K errors/month and scale up (100K, 300K, 500K, 1M, 3M, 5M… up to 50M+ per month) with transparent pricing increments
Error attachments (minidumps, additional files) have a separate attachments quota (1 GB up to 1 TB+)

Errors are usually the first knob teams turn up since they impact your ability to catch crashes and exceptions in production. But they’re not the only thing that affects your bill.

2. Spans: Tracing and performance visibility

What counts as a span?
A span is a single operation within a trace—like a database call, HTTP request, or function execution. A transaction is made up of multiple spans. Sentry uses spans to measure throughput, latency, and cross-service performance.

From a billing standpoint:

Each span, whether generated automatically by the SDK or manually, counts toward your Tracing spans quota.
Errors and spans are billed separately. An error inside a transaction counts as 1 error event plus however many spans that transaction includes.

Plan context:

Free and entry paid tiers include 5M spans/month by default.
You can scale spans in tiers: 5M, 10M, 20M, 50M, 100M… up to 10B spans/month.

This is where teams often over- or under-shoot. If you set sample rates too high on a high-throughput service, spans can dominate your bill. The fix is simple: set a sampling strategy that reflects where you actually need detailed tracing (e.g., higher rates on critical paths, lower on non-critical or very noisy services).

3. Session Replay: “Video-like” user session capture

What counts as a replay?
A replay is a captured user session—a video-like reproduction of page visits, mouse movements, clicks, taps, and scrolls for your site, web app, or mobile app. One user session = one replay (within your configuration).

Replays come with their own quota:

Default includes 50 replays/month on lower tiers.
You can configure replay quotas from 50 all the way up to 10M replays/month.

Replays do not count as errors or spans. They’re a separate line item because they’re heavier data and serve a different purpose: seeing the exact sequence of actions that led up to an error or slowdown.

Most teams start small with replays, then increase quotas once they see how useful playback is for debugging UI regressions, rage clicks, or mysteriously missing button presses.

Features & Benefits Breakdown

Here’s how the main usage-based primitives map to debugging value and cost:

Core Feature	What It Does	Primary Benefit
Error Monitoring	Captures error events with stack traces, environment, releases, and commits	See crashes and exceptions fast, with code-level context
Tracing (Spans)	Records spans within transactions across services	Debug slow endpoints and cross-service latency at code level
Session Replay	Captures video-like user sessions with clicks, taps, and scrolls	Reproduce user experiences without guessing

Outside this trio, you’ll also see usage for:

Logs: 5GB/month included on core plans, then +$0.50/GB beyond that.
Uptime Monitoring: 1 uptime monitor included, then +$1.00/monitor additional.
Cron Monitoring: 1 cron monitor included, then +$0.78/monitor additional.
UI Profiling: Pay-as-you-go, +$0.25/hr, helpful when you need CPU-level insight.

All of these bolt into the same workflow: something breaks or slows down → Sentry groups it into an issue → you pivot into traces, logs, replays, and profiling to identify root cause → optionally let Seer propose a fix or open a PR.

Ideal Use Cases

Best for production error monitoring with performance context:
Because you can combine Error Monitoring (errors), Tracing (spans), and Session Replay (replays) to see what users experienced, where the code slowed down, and where it failed—without paying for a monolithic “everything or nothing” package.
Best for teams that need predictable spend with room for spikes:
Because quotas and caps let you define a “normal” month and then handle incident spikes via controlled overages, rather than silently dropping data or blowing up the budget.

Limitations & Considerations

Event volume ≠ user count:
High-traffic or noisy services can generate huge spans and errors per user. You’ll want to tune sampling and SDK configuration, especially for background jobs and chatty services, so you’re not paying to trace every single heartbeat.
Not all event types are equal in storage/weight:
Replays and attachments consume more storage than a simple error event. They’re priced via their own quotas (replay count, attachments GB). Use filters and capture rules (e.g., sample only certain user segments or environments) to focus on valuable sessions.

Pricing & Plans

Sentry takes a layered approach: plan, base quotas, and pay-as-you-go.

Plan basics

From the official tiers:

Free:
- 1 user
- Unlimited projects
- 5K errors/month
- 5M spans/month
- 50 replays/month
- 5GB logs, +$0.50/GB additional
- 1 uptime monitor, +$1/monitor additional
- 1 cron monitor, +$0.78/monitor additional
Paid plans (Team, Business, Enterprise):
- Unlimited users/projects
- Error Monitoring base from 50K errors/month (configurable up to 50M+)
- Tracing from 5M spans/month, configurable up to 10B+
- Session Replay from 50 replays/month up to 10M+
- Logs: 5GB included, +$0.50/GB additional
- Uptime: 1 monitor included, +$1/monitor additional
- Cron: 1 monitor included, +$0.78/monitor additional
- UI Profiling: pay-as-you-go at $0.25/hr
- Attachments: 1 GB–1 TB+ tiers included as you scale

In addition, Seer (AI Debugging Agent) is an add‑on:

Unlimited root cause analysis, automated fixes, and code review on connected repos
Priced at $40/active contributor/month

How errors vs spans vs replays actually affect the bill

In a given month, your bill is influenced by:

Errors:
- Base quota (e.g., 300K errors) is included in your plan price.
- Overages above that quota are billed per additional error tier (for example, bumping from 300K → 500K).
- If you routinely exceed the current tier, it’s usually cheaper to increase the monthly errors quota than to live on overages.
Spans:
- Base quota (e.g., 5M, 20M, 100M spans).
- Overages billed per additional span block; again, sizing the quota to your normal traffic is cheaper than permanent overages.
- Spans can grow quickly with high sampling on chatty services, so sampling and instrumentation matter a lot.
Replays:
- Base quota (e.g., 50, 10K, 100K replays).
- You’re billed if you exceed that replay count.
- Turning on replays everywhere at 100% capture can get expensive; targeted sampling by environment, page, or feature works better.

Support usage (logs, monitors, attachments, profiling) will contribute to cost, but in practice the biggest levers for most teams are error volume and spans.

How budget caps and overages work

The usage-based model is only helpful if you can keep it under control. That’s where caps and budget controls come in.

1. Base quotas: your “normal” month

You define:

Monthly errors quota (e.g., 300K)
Monthly spans quota (e.g., 20M)
Monthly replays quota (e.g., 10K)
Additional quotas for logs (GB), attachments (GB), and monitors

These become your “included” volumes; they’re what your plan is priced around. If your actual usage stays under these, you don’t pay overages.

2. Pay-as-you-go overages

For each data type, you can optionally allow Sentry to continue ingesting when you hit your quota by enabling pay-as-you-go. Then:

Extra logs are billed at $0.50/GB
Extra uptime monitors at $1.00/monitor
Extra cron monitors at $0.78/monitor
Extra UI Profiling at $0.25/hr

Errors, spans, and replays follow a similar pattern: extra volume is billed according to the pricing configurator tiers. You can reserve more events in advance for discounts (“when you use more, you pay less”).

Think of this as shock absorption: when a bad deploy doubles your errors for a week, you pay more—but you don’t lose visibility in the middle of an incident.

3. Budget caps and hard limits

To avoid accidental runaway cost, you can configure Sentry to:

Set per-category caps so, for example, you allow overages on spans up to a certain dollar amount or percentage over quota.
Stop ingesting once a hard cap is hit for that category. In practice this means:
- For errors: new error events over the cap may be dropped until the next period.
- For spans: additional spans may be sampled or dropped based on configuration.
- For replays: new replays won’t be recorded.

The trade-off is straightforward:

Soft caps + generous overage = more complete data, less risk of data loss, more variable monthly bill.
Hard caps + tight quotas = strong budget control, but you have to be comfortable potentially losing some telemetry during spikes.

Most teams start with modest overage buffers and then tighten caps once they understand their baseline usage patterns.

Frequently Asked Questions

Does a single error with many occurrences count once or multiple times?

Short Answer: Each occurrence counts as an error event, even if they’re grouped into the same issue.

Details:
Sentry groups similar error events into issues to keep your inbox manageable, but billing is based on events ingested, not issue count. If a given exception happens 10,000 times, that’s 10,000 error events:

The SDK sends an event each time the error is captured.
Sentry groups them into a single issue with a count of 10,000.
Your error quota is reduced by 10,000 for that month.

You can use SDK sampling, rate limits, and environment filters to reduce noisy, low‑value error volume (e.g., bot traffic, known non-actionable errors) and keep your error events focused on what you actually intend to fix.

Do spans and replays get counted for free when an error happens, or separately?

Short Answer: They’re counted separately; an error inside a trace with a replay still consumes one error, multiple spans, and one replay.

Details:
Sentry connects context sources—errors, spans, replays, logs—into a single debugging workflow, but they’re priced per data type:

Error: The captured exception is one error event.
Spans: The transaction that led to that error might contain dozens or hundreds of spans, each counted toward your tracing quota.
Replay: If you have Session Replay enabled and the session was captured, that single user session consumes one replay from your replay quota.
Logs/Profiling: If you ingest logs or enable profiling, those resources are counted according to their own quotas as well.

This separation lets you tune each dimension independently. For example, you might keep error coverage high (no sampling), trace at 20% on high-throughput services, and collect replays only in production for critical user flows.

Summary

Usage-based error monitoring in Sentry is about clarity and control. Errors, spans, and Session Replay each have their own quotas and costs, so you can:

Capture the right mix of errors, performance data, and user session context
Scale volume as your traffic grows, with better unit pricing at higher tiers
Use budget caps and overage settings to absorb incident spikes without letting costs run unchecked

If you’re deliberate about SDK configuration and sampling, you can keep your bill predictable while still having enough data to trace through services, pinpoint slow code, and see exactly what users experienced when things went sideways.

Next Step

Get Started