Sentry Logs pricing in 2026: what the 5 GB allowance buys, and where it cracks

What Sentry Logs actually is, after August 2025

Sentry Logs is the structured-log ingest path Sentry GA-ed in 2025. The SDK accepts log records, attaches the active trace and span IDs, and ships them in the same envelope as errors. On the backend, logs are stored against the project, indexed by level and timestamp, and joined to errors through the trace ID so you can pivot from an exception into the surrounding log stream.

The product slot Logs occupies is the one most teams already filled with Loki, Datadog Logs, or a self-hosted ELK. Sentry's pitch is that errors and logs share infrastructure: the SDK is already there, the trace context is already wired, the project boundaries already match. You pay one bill instead of two and lose the cross-tool stitching problem.

The pricing model the August 27, 2025 change locked in: 5 GB of Logs ingest is included on every paid plan, and additional ingest is billed against your pay-as-you-go (PAYG) budget at a per-GB rate that depends on plan and region. There is no “Logs reserved” tier like the one Sentry offers for errors and spans. Either you fit in 5 GB or you pay on-demand.

The 5 GB floor on every paid plan

5 GB is what one decently instrumented backend service emits in two to three weeks, not a month.

A serialized Sentry log record runs 1–3 KB after the SDK adds trace ID, span ID, resource attributes, and any structured fields you attached. A service emitting one INFO log per request at 50 RPS averages around 130 GB per month before sampling. A service at 5 RPS lands closer to 13 GB. The 5 GB floor covers a single low-traffic service or a couple of cron jobs, not a production fleet.

The math that gets teams in trouble:

• Debug logs are bigger than they look. A debug line that prints two struct dumps balloons to 5–8 KB once trace context is appended. If debug stays on in staging or behind a feature flag in production, it dominates the bill.
• Exception context is logged twice. The exception itself ships as an error event; the surrounding context shows up as breadcrumbs and often as separate log lines if your framework auto-logs request bodies. The same incident shows up across three line items.
• Background workers and queues batch. A worker that processes a batch of 500 items and logs per-item progress at INFO is invisible in development and a Logs-bill driver in production.

The 5 GB floor is real value only at low traffic. Past a few RPS sustained, you should plan as if the floor is decorative.

The PAYG overage curve

Overage above 5 GB draws from the same PAYG budget your spans, replays, and attachments share. There is no isolated Logs cap.

The mechanics: you set a single PAYG budget at the org level. Every metered category that exceeds its included quota debits that pool. When the pool drains, ingest for all PAYG-funded categories drops or is rejected, depending on the category's behavior. For Logs specifically, ingest is rejected with a quota response and the SDK respects the standard rate-limit headers.

Two consequences operators hit:

• An incident drains the pool across categories. When something breaks at 3 AM, spans go up because retries spam the system, replays go up because more users hit the broken flow, and logs go up because every layer of your stack writes its alarm. The PAYG pool drains in minutes, and you lose Logs visibility while the incident is still active.
• The bill is back-loaded. PAYG bills at the end of the cycle. You see the consumption in real time on the Stats page, but the dollar number is a month-end surprise. Teams that watch the dashboard see the ingest rate and assume it is normal; the overage line on the invoice tells a different story.

The lever Sentry gives you is the PAYG cap itself. Set it low and you get rejection behavior during incidents instead of a surprise bill. Set it high and you absorb spikes at full cost. There is no third option inside the SaaS pricing.

Where 5 GB lasts and where it snaps

Realistic month-to-month numbers, based on a service emitting structured JSON logs with trace context attached:

• One cron job, hourly. ~10 MB/month. The 5 GB floor is essentially free.
• Background worker, 500 jobs/day, INFO per job + ERROR on failure. ~150 MB/month. Still well inside the floor.
• Internal API, 5 RPS sustained, INFO per request. ~13 GB/month. ~8 GB of overage, which at the typical PAYG rate is a small but visible monthly line.
• Customer-facing API, 50 RPS sustained, INFO per request + DEBUG behind a 10% sampling flag. ~145 GB/month. ~140 GB of overage. The overage line is now the biggest single component of your Sentry bill.
• The same API during an incident. A 30-minute window of doubled traffic and panicking middleware easily adds 20–40 GB on its own. The PAYG cap may trigger before the incident resolves.

The pattern: 5 GB is generous if you treat Logs as an exception-context tool and brutal if you treat it as a general-purpose log pipeline. The product invites the second interpretation. The pricing punishes it.

The hidden interaction with spans pricing

The August 2025 change tightened spans pricing at the same time it formalized Logs pricing. The two interact in ways that are not obvious from the pricing page.

When you attach a log to a span using the SDK's logger integration, the log ships as a Logs envelope item (counts against the 5 GB allowance) and increases the span's serialized size on disk. If you enabled tracing under the new plan and turned on Logs as a single “flip both switches” rollout, your spans bill and your Logs bill move together. A 50% spike in traffic is a 50% spike on both lines.

The shape that surprises teams: a service that was comfortably inside spans + included Logs at quarter-end traffic ends up with a doubled bill at peak. The two line items reinforce each other rather than averaging out.

If you are going to keep both on SaaS, sample them together. A 10% trace sample rate with logs auto-attached to sampled traces costs roughly 10% of the unsampled bill on both lines. A 100% trace sample with 100% log capture is the worst-case quadrant and the one most teams land in by default.

Sampling and log levels: the two levers that move the bill

You can lower the bill in exactly two ways: ship fewer log records, or ship smaller ones. Every concrete recommendation is a variation on one of those.

The fewer-records lever:

• Raise the SDK log level. Default to WARN in production. INFO is the band that drives most bills.
• Sample by trace, not by record. Attach logs only to traces that are kept by your trace sampler. Tail-based sampling at the OTel Collector lets you keep 100% of error traces and 1% of healthy ones.
• Suppress hot loops at the source. A retry-with-backoff that logs every attempt is a Logs bill. Log the first attempt and the final outcome; suppress the middle.

The smaller-records lever:

• Stop dumping request bodies into logs. Frameworks that auto-log request.body on errors will write the entire payload, including base64-encoded uploads. Strip large fields at the SDK before_send hook.
• Move stack traces to the error event. If you log error.stack at the error site, you have shipped the stack twice: once as the log line, once as the error event. Use the error event.
• Compact structured fields. A log with 40 attributes is paying for 40 attributes. Audit the resource attributes your SDK is auto-attaching; most services need maybe a dozen.

What changes when you self-host the log line item

Self-hosting flips Logs from a metered category into a fixed-cost component. You pay for disk and operator time. The per-GB cliff disappears.

The relevant numbers for an urgentry-style single-binary deployment:

• Storage. SQLite or Postgres, on the same volume as your error events. A month of logs from the 50 RPS customer-facing API example above is ~145 GB on disk before compression, ~30–50 GB after. Block storage on a major cloud is roughly $0.08–$0.10/GB-month, so the storage line is $3–$5/month at the volume that costs hundreds on SaaS.
• Compute. The single-binary footprint at that ingest rate fits in 1 vCPU and ~256 MB RSS. A $5 VPS is enough. There is no Kafka, no Redis, no ClickHouse to keep upright.
• Operator time. Roughly the same as any other small Go binary: occasional upgrades, occasional restart on host maintenance. Budget 30 minutes/month if nothing breaks, a few hours/year if something does.

The shape of the spend changes too. On SaaS, costs scale with traffic and spike with incidents. On self-host, costs are flat against traffic and rise with the disk you provision. Forecasting becomes a one-number question: how big a volume do you want to keep, for how long.

The decision tree: SaaS Logs vs self-host

Stay on Sentry Logs if:

• You are under 5 GB/month and likely to stay there for the next two quarters.
• You already pay for Sentry SaaS errors and would not put a VPS in front of a separate log store anyway.
• The team is small enough that one operator avoiding one new system is worth more than a few hundred dollars in monthly overage.

Move Logs to self-host (with or without urgentry handling errors) if:

• Your overage line is consistently larger than your error line on the invoice.
• Your PAYG cap fired during an incident and you lost log visibility while debugging.
• You need longer retention than Sentry's defaults for compliance or regression analysis, and the storage upcharge for that retention dwarfs the disk cost of running it yourself.
• You are already self-hosting errors. Adding logs to the same backend is mostly schema work, not new infrastructure.

The honest call for most teams in the 50–500 GB/month band: self-hosting Logs while staying on SaaS for errors and replay is the lopsided trade that pencils out fastest. Logs are the bulkiest signal and the one with the lowest per-record value. Moving them moves the most dollars per hour of operator work.

Frequently asked questions