Track the signals that matter, slice by any attribute at query time, and jump straight to the trace when something spikes — without getting penalized for adding context.
A spike isn't a number on a graph — it's a clickable path to the exact request, span, and line of code.
Drill from a p95 outlier into the slow span that produced it
Jump from a counter increment to the issue and stack trace behind it
Correlate metric movements with releases, feature flags, and deploys automatically
Tag every measurement with the dimensions you actually debug with — customer_id, route, region, plan, build SHA. High cardinality is the default, not a limit. Emit raw measurements, then ask new questions later — without redeploying.
Counters, gauges, and distributions — first-class, with the tags you need
Slice and group after the fact — like grouping checkout.failed by customer_id
Filter with structured queries like route:"/checkout" AND region:"eu-west"
Alert on any structured dimension, not just pre-canned rollups
Calculate error rates and conversion ratios from the metrics you already emit.
Aggregate by sum, avg, count, or p50/p95/p99
Combine up to 26 queries with equations like A / B for ratios, or (A + (B / 2)) / C for Apdex
Use derived series in dashboards and alerts
Combine metrics with arithmetic to derive the number you actually care about — ratios, deltas, and composite scores like Apdex. Reference up to 26 metric queries (A, B, C…) in a single equation: A / B for a failure ratio, A - B against a baseline, or (A + (B / 2)) / C for a satisfaction score.
Alert on any structured dimension. Route to the on-call who owns that surface.
Compose error rates, latency, and throughput next to the issues and traces they describe.
Traditional metrics tools tell you if something changed. Trace-connected metrics tell you why. Metrics are automatically tagged with trace_id and span_id — so when checkout.failed spikes, you click into an exemplar and land in the exact trace, spans, logs, and errors that produced it. Debugging stops being speculation.
View related metrics — error rates, latency, throughput — alongside the issues and traces they describe for one-pane root-cause analysis.
With Metrics, we can have a more central location for all our error tracking and data analysis.
I was able to get our first metrics in Sentry very quickly!
All Sentry plans come with 5 GB. Additional usage beyond that costs $0.50/GB. Usage will be applied to your pay-as-you-go budget.
Traditional metrics tools punish you for the tags you actually need and live in a different tab from your errors and traces. Sentry treats high cardinality as the default for application-level signals, and links every emission to the trace and issue behind it.
The result: you go from a metric spike to the trace, span, and stack frame that caused it — without leaving Sentry.
Not today — and it's a deliberate choice. OTLP metrics are pre-aggregated before they reach us, which strips out the high-cardinality detail that makes our query model useful. If you need OTel-style infra metrics, pair Sentry with your existing metrics backend.
If you already have the Sentry SDK installed, you're a few lines away from emitting metrics. Call Sentry.metrics.count(), Sentry.metrics.gauge(), or Sentry.metrics.distribution() directly from your code — no separate import, no extra service to wire up. Release, environment, and SDK context are attached automatically.
Check out our docs to read more.
Sign up for our newsletter.
And yes, it really is monthly. Ok, maybe the occasional twice a month, but for sure not like one of those daily ones that you just tune out after a while.
Get started with the only application monitoring platform that empowers developers to fix application problems without compromising on velocity.
