Skip to main content
Performance Monitoring gives you end-to-end visibility into how your application behaves under real conditions. You can trace a single user request across every service it touches, measure latency percentiles, track Web Vitals, and get alerted when things slow down.

​
Core concepts

Transactions

A transaction represents a single operation — an HTTP request, a background job, or a page load. It’s the top-level unit Sentry measures.

Spans

Spans are the individual steps inside a transaction — a database query, an external API call, a template render. Each span has a start time and duration.

Traces

A trace connects spans across multiple services. When a frontend page load triggers a backend API call that queries a database, all three appear in the same trace.

​
Distributed tracing

When you instrument multiple services with Sentry, a trace ties them all together using a propagated trace_id. You can follow a single user’s request from the browser, through your API gateway, into your microservices, and down to the database — all in one waterfall view. Sentry automatically propagates trace context in HTTP headers (using the W3C traceparent standard) when you use the SDK’s HTTP instrumentation.

​
Transaction performance

The Performance section in Sentry shows aggregated metrics for every transaction your application receives:
MetricDescription
P50Median response time — half of requests are faster
P7575th percentile — a good proxy for typical user experience
P9595th percentile — captures the slowest 5% of requests
P9999th percentile — your worst-case outliers
ThroughputRequests per minute
Failure ratePercentage of transactions that errored
Click into any transaction to see a breakdown by span operation type (db, http, cache, etc.) and identify where time is being spent.

​
Web Vitals

For browser-instrumented pages, Sentry tracks the Core Web Vitals defined by Google:
VitalWhat it measures
LCP (Largest Contentful Paint)How long until the main content is visible
FID (First Input Delay)How quickly the page responds to the first interaction
CLS (Cumulative Layout Shift)How much the page layout shifts unexpectedly
FCP (First Contentful Paint)How long until any content is painted
TTFB (Time to First Byte)How long the browser waits for the first byte from the server
Sentry scores each vital as Good, Needs Improvement, or Poor using Google’s thresholds, and shows you the distribution across all page loads.

​
N+1 query detection

Sentry automatically detects N+1 query patterns — where your code issues the same database query repeatedly in a loop instead of batching them. These show up as performance issues in the Performance tab, linked to the specific transaction and code location causing the problem.

​
Instrumenting your code

Most frameworks are instrumented automatically. When you initialize the Sentry SDK, it patches common libraries (Express, Django, Flask, Rails, etc.) to create spans for HTTP requests, database queries, and more — with no additional code.
import * as Sentry from "@sentry/node";

Sentry.init({
  dsn: "https://your-dsn@sentry.io/project-id",
  tracesSampleRate: 1.0, // Capture 100% of transactions
});

import sentry_sdk

sentry_sdk.init(
    dsn="https://your-dsn@sentry.io/project-id",
    traces_sample_rate=1.0,
)
Set tracesSampleRate between 0.0 and 1.0 to control what fraction of transactions Sentry records. For high-traffic apps, start with a lower value like 0.1 (10%) to manage volume.

​
Sampling

Sentry supports uniform sampling (send X% of all transactions) and dynamic sampling (prioritize transactions with errors, specific users, or custom criteria). Configure sampling in Sentry.init: 
Sentry.init({
  tracesSampleRate: 0.2, // 20% of all transactions

  // Or use a function for dynamic sampling
  tracesSampler: (samplingContext) => {
    if (samplingContext.transactionContext.name === "/health") {
      return 0; // Never sample health checks
    }
    return 0.2;
  },
});

​
Performance dashboard

The Performance section in your Sentry project gives you:
  • A list of all transactions, sortable by P95 latency, throughput, or failure rate
  • A transaction summary page for any individual transaction showing latency distribution, related issues, and span breakdown
  • Web Vitals summary for frontend projects
  • Trends view to spot transactions that got slower or faster between releases