Sentry Blog RSS

Routing OpenTelemetry logs to Sentry using OTLP

Thu, 05 Mar 2026 00:00:00 GMT

If you've already instrumented your app with OpenTelemetry, you don't have to rip it out to use Sentry. Two environment variables and your logs start flowing into Sentry, no SDK changes, no re-instrumentation. Here's how to set it up in a sample app, and when the native Sentry SDK might be the better call.

Why you'd use OTLP instead of the native SDK

The main advantage of OTLP is that your logging code stays decoupled from any specific observability backend. You can switch where logs go by changing a few config lines. That's useful if you:

Already have OpenTelemetry logging in place
Want to send logs to multiple backends
Need vendor-neutral instrumentation
Work with AI or LLM frameworks that use OpenTelemetry by default
Want to use the broader OpenTelemetry ecosystem

If you're starting from scratch and only need Sentry, the native Sentry SDK is probably the better call. With the native SDK, you get issue creation from logs, session replay integration, automatic breadcrumbs, and built-in error correlation. Ingesting OpenTelemetry traces and logs with Sentry via OTLP endpoints is still in beta and currently lacks these integrated features.

Guide prerequisites

Before we start, you need:

A Sentry account (the free tier works)
Node.js 18 or later installed
Basic familiarity with Express.js

If you don't have a Sentry project yet, create one now. Select Express as the platform. You can skip the DSN setup instructions because you'll use the OTLP endpoint instead.

Get your Sentry OTLP credentials

Sentry exposes separate OTLP endpoints for logs and traces. In this guide, we're focusing on the Logs endpoint. To find your OTLP credentials:

Click Settings in the left sidebar.
Under the Organization section in the Settings sidebar, click Projects.
Find your project in the list and click on it to open the project settings.
In the project settings sidebar, click Client Keys (DSN) under the SDK Setup section.
Select the OpenTelemetry tab. Click the Expand button to see all OTLP endpoint values.

Keep this tab open. We'll use the following values in the next step:

OTLP Logs Endpoint: The URL where Sentry receives logs (which looks like https://o{ORG_ID}.ingest.us.sentry.io/api/{PROJECT_ID}/integration/otlp/v1/logs)
OTLP Logs Endpoint Headers: The authentication header (which looks like x-sentry-auth=sentry sentry_key={YOUR_PUBLIC_KEY})

One thing worth knowing: most OTLP exporters expect headers as raw key/value pairs, not full header strings. You'll need to parse the header in your app. We'll handle this in the setup below.

Connect your OpenTelemetry app to Sentry

We'll use a sample payment processing service that already has OpenTelemetry logging instrumentation. You don't need to touch the logging code itself. Just point it at Sentry's OTLP endpoint.

Clone the starter app

Run the following commands to clone the payment processing app:

This app includes the OpenTelemetry SDK already configured, structured logging throughout, multiple log severity levels (INFO, DEBUG, WARN, and ERROR), and rich log attributes for every entry.

Configure Sentry as the OTLP destination

Create a .env file in the project root:

Now edit .env and add your Sentry OTLP credentials from the previous step:

Replace the placeholders with your actual Sentry credentials. The OTEL_SERVICE_NAME will let you filter logs by service in Sentry later.

That's it. Two config lines and OpenTelemetry logs are flowing to Sentry.

Test the integration

Start the app:

You should see:

Generate some logs

In a new terminal window, send a request to process a payment:

You'll get a JSON response confirming the payment:

View the logs in Sentry

Now let's see what this looks like in Sentry's Logs view:

Go to your Sentry project.
Navigate to Explore in the left sidebar, then click Logs.

You'll see a list of log entries from your payment processing workflow. Each log shows a timestamp, severity indicator (colored dot), and message.

Explore log attributes

Click on any log entry to expand it and see all its attributes.

For example, the High-risk transaction detected log includes attributes like the following:

fraud_check.score: 97.98
fraud_check.threshold: 70
fraud_check.reason: unusual_amount_pattern
user.id: user123
transaction.id: txn_1762164637756_0hscczobm
severity: warn

All of these are searchable. To add any attribute as a filter, hover over it, click the overflow menu (three dots), and select Add to filter.

How OpenTelemetry logging works

Here's what's happening under the hood, in case you're applying these patterns to your own app.

OpenTelemetry SDK initialization

The instrument.js file configures the OTLP exporter and wires up the logger provider:

These are the key parts:

OTLPLogExporter sends logs to the OTLP endpoint.
LoggerProvider manages the logging system.
BatchLogRecordProcessor groups log records before export, which reduces network overhead at scale.

Emitting structured logs

The index.js file imports instrument.js first, then creates a logger and emits records:

Here's how we emit a structured log:

Each call to logger.emit() takes a severity level, a message body, and a set of attributes. The attributes are what make logs searchable — the more context you add here, the easier it is to find specific events later.

Log severity levels

OpenTelemetry supports six severity levels:

Adding rich attributes

The more attributes you add, the easier it is to debug issues. Here's an example from the fraud detection path:

All these attributes are searchable in Sentry, so you can find specific transactions quickly without scanning log text.

OTLP vs native Sentry SDK

Both approaches send logs to Sentry. The difference is in what you get automatically.

Setup and configuration

OTLP

Native Sentry SDK

Note that Sentry.logger requires Sentry JavaScript SDK v9.41.0 or above.

Emitting logs

OTLP

Native Sentry SDK

With OpenTelemetry, you specify both severityNumber and severityText manually. The Sentry SDK infers both from the method you call (info(), warn(), and so on). The SDK also associates logs with errors, transactions, and user sessions automatically, without any extra setup.

Log levels

OTLP

Native Sentry SDK

What's next

You now have OpenTelemetry logs flowing into Sentry. A few ways to get more value from here:

Add context to your logs. The more attributes you add, the easier it is to debug issues. Add user IDs, request IDs, transaction IDs, feature flags, or any relevant business context to every log entry.
Use consistent attribute naming. Follow OpenTelemetry Semantic Conventions for standardized attribute names. This keeps your logs consistent and easier to search across services.
Set up alerts. Configure Sentry alerts to notify you when certain log patterns appear — ERROR logs exceeding a threshold, or high-risk transactions crossing a fraud score cutoff.
Combine logs with traces. If you're also sending traces to Sentry, you can correlate them with logs to get a complete picture of your application's behavior.

OTLP logging support is still in open beta. If you run into a limitation not listed here, open an issue on GitHub. That's the fastest way to get it on our radar.

React Native SDK 8.0.0 is here

Thu, 19 Feb 2026 00:00:00 GMT

We just released React Native SDK 8.0.0, here's what's new, and what's changed.

It's been a while since the last major version. The last major release, 7.0.0, shipped on September 2, 2025. After 13 minor and 2 patch releases, it's finally time for a new major version to land: 8.0.0. This version is a maintenance and capability major. This means we:

Added app start error capture with native initialization
Upgraded core native dependencies
Bumped minimum version requirements

It should be straightforward to upgrade, but check the migration guide for your setup.

Changes you'll want to know about

Most of the changes in version 8 fall into two buckets: new capabilities and updated dependencies. Here are the essentials:

App start error capture

Sentry can now capture crashes and errors during React Native bridge setup, bundle loading, and native module initialization — not just after Sentry.init() runs on the JavaScript side. In previous versions, this required complicated configuration and manual native initialization.

In version 8, you can initialize Sentry at the native layer using a sentry.options.json configuration file and new native APIs. This lets the SDK capture app start errors and native crashes from the very beginning of the app lifecycle. You can find more information in the React Native documentation.

Updated native dependencies

Cocoa SDK v9
Sentry CLI v3
Android Gradle Plugin v6

Updated minimum supported versions

With the release of 8.0.0, the minimum version requirements have changed.

Apple Platforms

iOS: 15.0+ (previously 11.0+)
macOS: 10.14+ (previously 10.13+)
tvOS: 15.0+ (previously 11.0+)

Android

Android Gradle Plugin: 7.4.0+
Kotlin: 1.8+

Upgrading to version 8

Simply update your package manager to use the latest version of version 8 and then check the migration guide to see if you need to change anything. That's all there is to it for most setups. It would look something like this:

Update @sentry/react-native to the latest 8.x version in your package manager.
Follow the v7 to v8 migration guide to adjust minimum versions and build configuration (iOS/macOS/tvOS deployment targets, Android Gradle Plugin, Kotlin, and self-hosted Sentry if applicable).
Optionally enable app start error capture using sentry.options.json and native initialization.

What about version 7?

We have stopped feature development for version 7 and will only ship critical bug fixes. You still can use version 7 and aren't forced to upgrade to version 8, but we still recommend updating to the latest major version if possible.

If you're ready to upgrade

If you're able to, give version 8 a try. Enable native initialization if you want full coverage from app launch. And if something breaks, or even just feels off, open an issue. You can also find us on Discord. We'll help you sort it out.

From random chunks to real code — wiring up Next.js source maps in Sentry

Tue, 17 Feb 2026 00:00:00 GMT

When you ship a Next.js app, the React and TypeScript you write aren’t what your users actually download. Next.js compiles, minifies, splits, and shuffles your code into chunks in ways that are great for performance and terrible for debugging.

This post shows you how that pipeline works, how source maps and debug IDs connect it all back to your original code, and how to wire things up so Sentry shows you real file names and line numbers instead of an unreadable stack trace.

What actually happens to your code

In a typical Next.js app, your React + TypeScript source goes through a build pipeline that compiles it to JavaScript, HTML, and CSS, minifies that output, and splits it into chunks so users only download what they need.

All of this is good for page load. It's less good for you when an error happens and your stack trace now points into static/chunks/12345-something.js instead of app/page.tsx.

Your code goes from something you recognize to something you really do not. That's where source maps step in. Each of those compiled bundle chunks gets two important pieces of metadata — a debug ID and a sourceMappingURL that points to the corresponding source map.

Sentry uses the debug ID on the uploaded minified file to find the matching debug ID on the uploaded source map. Once it has that pair, it can de-minify the stack trace, map it back to the original file, line, and column, and show you the code you actually wrote, not just the code your bundler generated.

Why dev tools show nice stack traces but Sentry shows chunks

In development, things look fine in the browser. You run the app in dev, you throw a sample error, and your browser devtools show a readable stack trace with your real filenames and source.

That's because when you run next dev, the browser’s got direct access to local source maps and your original source files. It can resolve everything on its own, without Sentry.

If you point that same dev build at Sentry, Sentry only sees what you send it. Without uploaded source maps, it just sees whatever bundles and chunk files the dev build produced. The result is a browser with a nice, human-readable stack trace and Sentry with a stack trace full of randomly named chunks.

Those chunk names change across builds, which means you can easily end up with the same logical error appearing multiple times as different issues in Sentry.

Use Sentry for production, Spotlight for local debugging

If you're actively working on a feature and throwing errors on every refresh, you're going to generate fresh chunks, send lots of near-duplicate errors, and burn through Sentry quota on problems only you ever saw.

For that local dev loop, use a tool like Spotlight. It's built for local development, works similarly to Sentry, and keeps all that debug noise out of your Sentry org so you can save Sentry for production issues from actual users.

Simulating a production build so Sentry gets your source maps

Sentry cares about the production artifacts — the optimized bundles and matching source maps that your real users hit. To simulate a production environment locally and make sure Sentry sees what it needs, build your app and start it:

npm run build creates the optimized production build where Sentry hooks in, and npm run start serves that build as if it were running in production.

This run goes through the same pipeline as your deployed app, and it's during this process that Sentry hooks in to upload your bundles and source maps.

What Sentry does during the build step

During the production build (when you run npm run build), Sentry hooks into the "after production compile" step. In that phase, Sentry collects the generated chunks, finds their source maps, and uploads both to Sentry.

After uploading, Sentry deletes the source maps from the build output so they don't ship to the browser. That gives you readable stack traces in Sentry, without handing over your original source code to every user who opens devtools.

If you want to see the more general ways to upload source maps (beyond Next.js), check out the uploading source maps docs.

Verifying that source maps are wired up correctly

Once you've run npm run build and npm run start, trigger that same sample error again and compare. In the browser console, you should now see a long, minified stack trace. That's expected. The browser no longer has access to your source maps in this production-style setup.

In Sentry, refresh the Issues page and open the new error. The stack trace should now point to your real Next.js files with the code you actually wrote. If the Sentry stack trace looks readable and matches your source, your source maps are wired up correctly.

In Sentry, source maps live in your project settings. Go to Issues, use the project selector to pick your Next.js project, click Project Settings, and in the sidebar, open the Source Maps page.

You’ll see all source maps uploaded for that project. For a Next.js app, you might see a client bundle, a server bundle, and an edge bundle. Seeing multiple entries for the same release is normal. Next.js just builds different bundles for different runtimes.

If source maps aren't behaving the way you expect (for example, Sentry still shows chunked or minified frames), go to the Source Maps page for your project, delete the existing source maps, rerun your production build with npm run build, and start the app again with npm run start and trigger an error.

This triggers a clean upload and often fixes issues caused by stale or mismatched files.

Double-checking your Next.js and Sentry configuration

If you're building your app but no source maps are appearing in Sentry, it usually comes down to configuration.

In your Next.js + Sentry setup, double-check that your Sentry organization is set correctly, the Sentry project is the one you actually expect, and you're providing a valid auth token.

You can set the auth token either directly in your Sentry-related config or via the SENTRY_AUTH_TOKEN environment variable in whatever environment is running your builds (local, CI, Vercel, etc.).

As long as the environment variable is in place, you don't need to hardcode it in your config.

Where to go when you're still stuck

If you've rebuilt the app in production mode, cleaned up and reuploaded source maps, and double-checked your Sentry config and environment variables, and your stack traces still look wrong, check the docs for Next.js source maps and the troubleshooting section under that page.

Those walk through common misconfigurations, show known-good examples, and give you a checklist to compare against your own setup.

And if you still have questions after that, let us know. We're happy to help you get from random chunk names back to the code you actually wrote. Find us on Discord, or if you're new to Sentry, you can explore our interactive Sentry sandbox or sign up for free.

AI-driven caching strategies and instrumentation

Fri, 13 Feb 2026 00:00:00 GMT

The things that separate a minimum viable product (MVP) from a production-ready app are polish, final touches, and the Pareto 'last 20%' of work. Most bugs, edge cases, and performance issues won't show up until after launch, when real users start hammering your application. If you're reading this, you're probably at the 80% mark, ready to tackle the rest.

This article covers application caching: how to use it for cutting tail latency, protecting databases, and handling traffic spikes, plus how to monitor it once it's running in production.

This article is part of a series of common pain points when bringing an MVP to production:

Paginating Large Datasets in Production: Why OFFSET Fails and Cursors Win
AI-driven caching strategies and instrumentation (this one)

Building a mental model for caching

Good caching multiplies your performance, scalability, and cost efficiency. Done right, it gives you sub-millisecond responses and absorbs traffic spikes without crushing your origin servers. Done wrong (aggressive caching, bad invalidation, wrong strategies) it creates subtle bugs, stale data, and degraded user experience (UX) that's hard to debug and usually only shows up after it's already affected a lot of users.

Before looking for caching opportunities, you need a mental model for what should and shouldn't be cached. Here's a checklist:

✅ Cache if most are true:

Expensive: slow CPU, slow input/output (IO), heavy DB, big joins/aggregates, external application programming interface (API)
Frequent: called a lot (high requests per minute (RPM)) or sits on hot paths (page load, core API)
Reusable: same inputs repeat (low key cardinality)
Stable-ish: data doesn't change every second (or can tolerate staleness)
Spiky load: bursty traffic where cache absorbs thundering herds
Tail hurts: P95/P99 is bad, and misses correlate with slow requests
Safe to serve stale: user impact low, or can use stale-while-revalidate (SWR)
Invalidation is easy: time to live (TTL) works, or updates have clear triggers
Small-ish payload: memory cost reasonable, serialization cheap

❌ Don't cache (or be very careful) if any are true:

High cardinality keys: per-user / per-page / per-filter explosion → mostly misses (pagination is a special case - see note below)
Highly mutable: correctness demands freshness
Personalized / permissioned: easy to leak data via key mistakes
Hard invalidation: no clear TTL, updates unpredictable
Already fast: saving 5ms isn't worth complexity
Cache stampede risk: expensive recompute + synchronized expiry (needs locking / jitter)

There's a special rule for caching paginated endpoints - cache page 1 + common filters first. Page 1 and a small set of common filters are usually hot and reused, so caching pays off. As page numbers increase, key cardinality explodes and reuse collapses, so deep pages will naturally miss and that's fine. Optimize for protecting the backend and reducing tail latency on the entry points, not for achieving uniform hit rates across all pages.

Finding caching opportunities in production

Once you know what should be cached, the next question is where caching will actually matter. In production systems, good caching candidates show up through pain, usually in three forms.

Backend pain (start here)

For backend and full-stack systems, this is the most actionable signal.

Look for:

Transactions with bad P95/P99
Endpoints with heavy database (DB) time
Repeated queries, joins, aggregates
Fan-out (one request triggering many downstream calls)
Lock contention or connection pool pressure

These are places where caching immediately reduces real work.

User pain (confirmation)

Slow page loads, janky interactions, timeouts. Web Vitals like Time to First Byte (TTFB), Largest Contentful Paint (LCP), and Interaction to Next Paint (INP) help confirm that backend slowness is actually affecting users. They're most useful once you already suspect a backend bottleneck.

Cost pain (the long-term signal)

Even if your users aren't complaining yet, repetition is expensive:

High DB read volume
Paid external API calls
Recomputed rollups and counts

Cost often lags behind performance problems, but it's a strong motivator once traffic grows.

A simple prioritization heuristic is cost density:

requests per minute * time saved per request

An endpoint that's moderately slow but hit consistently is usually a better caching target than a pathological endpoint nobody touches.

Example: a slow paginated endpoint

Consider a paginated endpoint performing a heavy database query with no caching.

In Sentry > Insights > Backend, filtering by API transactions (above the table) surfaces this:

The GET /admin/order-items endpoint has potential for caching. Let's dive into it. I'll pick a slower event and inspect the trace view:

From the screenshot, we can see:

776ms total duration
731ms spent in a single DB span
Multiple joins
LIMIT + OFFSET pagination
Poor TTFB in Web Vitals

Against the checklist:

✅ Expensive (heavy db query, joins)
✅ Frequent (high throughput)
✅ Stable-ish (can tolerate brief staleness)
✅ Tail hurts (bad P95)
✅ Invalidation is easy (writes are controlled)
⚠️ High cardinality key (pagination)

This is a strong candidate for selective caching, not blanket caching.

Applying and instrumenting caching

Sentry comes with Cache Monitoring too. It helps you see your caching hit/miss rates across your application, and inspect specific events captured in production when the cache was either hit or missed.

Instrumenting caches can be done both automatically and manually. If you're using Redis, you can leverage the automatic instrumentation. If not, manual instrumentation is just as easy.

The most straightforward approach is to just ask Seer to do it for you. At the time of publishing this article, Seer's "open-ended questions" feature is private access only, but I'll give you a little sneak peek. You can access it with Cmd + / and straight up ask it to instrument caches for you:

Seer will then open a PR on your repo, so you can merge it and be done with it.

In case you don't have access to this Seer feature yet, this is all you need to do to instrument your caches:

That's it. All we need to do is wrap the redis.get and redis.setex with Sentry.startSpan and provide caching-specific span attributes. If you're not using JavaScript on your backend, you can simply rewrite these functions in your language of choice. As long as you're sending spans that have the correct op and attributes, you'll get caches instrumentation right.

Now we can just use these two functions:

Monitoring and optimizing caches

Once we deploy this we start seeing caches coming in:

The data shows 75% Miss Rate on that endpoint. That's neither good nor bad by itself. The goal is not to reach 0% miss rate. If you do, you're probably hiding bugs. There is no "goal value" for the miss rate you should aim for. The miss rate % should only align with your expectations. 75% Miss Rate on this endpoint might make sense, but there also might be room for optimization. Let's click into the transaction to see actual events:

From the screenshot above we can see that cache hits happen only on page 1, and misses on the other pages. And that's because we followed the caching paginated endpoint advice - only cache page 1 and common filters. Users were visiting multiple pages, but Page 1 accounted for 25% of the visit, hence the 75% Miss Rate. From the Transaction Duration column we can see that Page 1 loaded in under 40ms, while for other pages the users had to wait >700ms.

So our caching implementation is working, and users are experiencing faster page loads. From this point on we'll know that for our /admin/order-items endpoint the normal miss rate sits around 75%. If we introduce a bug later on, for example buggy cache keys (missing params, extra params), new filters or sorting, per-user or per-flag keys creeping in, accidentally including volatile data in keys (timestamps, request IDs, locale), or mess up the TTL, this number is going to shoot up, and we'll see it in the chart. A spike in the chart will indicate to us that we broke caching and the users are experiencing slowdowns.

AI-assisted cache expansion in production

Remember the "cache only page 1 + common filters" rule? We're going to bend it a little bit. If we want to bring down the 75% Miss Rate above, we'll need to expand caching to cover more pages than just page 1, but we have to be careful not to over-expand because we'll bloat our Redis instance.

Here's a practical AI-assisted approach to help make a good cache expansion decision:

You can use Sentry Model Context Protocol (MCP) to pull all the cache.get spans from your project and group them by the cache.key property, and then ask the agent to suggest how we can expand the caching. Looking at the screenshot, we can see that Page 1 remains with the most hits, but Pages 2 - 6 have significant traffic too. Long-tail pages like 7 and 10 have minimal traffic so no need to cache, and there's also some test data that it discarded. It suggested me to expand the cache to Page 3. Let's see how that affects the Miss Rate:

Would you look at that! We're now at 30% Miss Rate, down from 75%. This means roughly only 1 in 3 requests will hit the database. But it's important to keep an eye on Redis memory as well. Pushing caching from Page 1 to Page 3 might bloat our Redis instance, and in that case caching won't be worth it. Redis bloat = hot paths evictions, which in other words means we'd be undoing the performance gains we got from caching in the first place.

Alerting on miss rate deviations

The last thing you want to do is to set up an alert that notifies you (email, Slack) when there's an anomaly in cache misses. Head to Sentry > Issues > Alerts, pick Performance Throughput, and create an alert with the following options:

Make sure you pick your project and environment correctly
You'd want to filter on cache.hit being False, and on your cache.key as well
Set the thresholds to Anomaly
Start with High level of responsiveness, and tune later
For Direction of anomaly movement you'd want Above bounds only so you only get notified on cache miss increases
Lastly, define your action, whether you want an email to yourself, or your team, or a slack message in a specific channel
Name it and hit "Save Rule"

That's it. Now if you accidentally break the caching mechanism, it'll result in a flood of cache misses, and Sentry will pick it up and notify you about it. You're free to filter as you want, and create as many alerts as you want. cache.hit and cache.key are not the only attributes you can filter on. Play with the filter bar to figure out all the ways you can filter on.

Where to go from here

At this point, caching is working. The endpoint is faster, the database is protected, and you have a baseline Miss Rate that reflects normal behaviour. From here on, the work is less about adding caching, and more about making sure it keeps doing what it's supposed to do.

The first thing to watch is Miss Rate deviations, not the absolute number. A stable line that suddenly jumps usually means something changed: a cache key bug, new filters or sorting, increased cardinality, or a TTL or invalidation mistake introduced during a deploy. Those changes tend to show up in cache metrics before users start complaining.

Next, always read Miss Rate together with latency. A higher Miss Rate that doesn't affect P95/P99 is usually harmless. A higher Miss Rate that brings the database spans back into the critical path is a regression worth acting on.

As you expand caching, keep an eye on Redis memory and evictions. Improving hit rates by caching more pages only helps if hot keys stay resident. Memory pressure that causes frequent evictions can quietly undo your gains and make cache behaviour unpredictable.

Finally, revisit cache boundaries as traffic evolves. Usage patterns change. What was a long-tail page last month may become hot after a product change or a new workflow. Cache strategies should evolve with real traffic, not stay frozen around initial assumptions.

If you treat cache metrics as guardrails (baseline Miss Rates, latency correlations, and post-deploy checks) caching becomes a stable part of your system instead of a fragile optimization you're afraid to touch.

Sentry acquires XcodeBuildMCP

Wed, 11 Feb 2026 00:00:00 GMT

Today we're announcing that Sentry has acquired XcodeBuildMCP, an open source MCP server that gives AI agents the ability to build, test, and debug native iOS and macOS apps.

XcodeBuildMCP has become a go-to tool for agentic Apple-platform development, with more than 4,000 GitHub stars and an active community. It unlocks the full developer loop: build, run, debug, interact, and verify, allowing users to stay in their preferred agentic development environment.

As part of this acquisition, the creator and maintainer Cameron Cooke will also join the Sentry team to help us continue to improve Sentry's mobile tooling and the new agentic development landscape.

Why this fits Sentry

Sentry is focused on making software more reliable and giving developers the fastest path from idea to production. For mobile teams, that path is still harder than it should be and was one of the reasons we also acquired Emerge Tools in 2025.

Apple platform tooling has again been slow to embrace agentic workflows, and developers are increasingly working in tools like Cursor, Claude Code, and Codex CLI rather than heavyweight IDEs.

XcodeBuildMCP helps close that gap. It gives those agents the same real-world capabilities a developer has, which means they can iterate autonomously and verify changes instead of constantly handing control back to a human.

What XcodeBuildMCP enables

Key capabilities include:

Build, run, and test apps on devices and simulators
Attach a debugger, inspect stack traces, and execute code
Capture simulator screenshots
Interact with running apps by tapping, swiping, and typing
Capture and stream runtime logs

This is the closed loop developer workflow that makes agentic coding practical on Apple platforms.

To get started, all you have to do is add this configuration to your MCP client of choice:

Example workflow

XcodeBuildMCP turns high-level requests into working features. Here's what a typical interaction looks like when an agent has access to the full development loop:

User: "Add dark mode support to my app."

Agent:

Edited Theme.swift
Edited Settings.swift
XcodeBuildMCP: Found app project and build scheme
XcodeBuildMCP: Built and launched the app in the simulator
XcodeBuildMCP: Navigated to Settings
XcodeBuildMCP: Toggled the dark mode switch
XcodeBuildMCP: Captured screenshot
Verified dark mode is enabled

Agent Response: "I've added dark mode support and verified it in the simulator."

How this fits alongside Apple's MCP tooling

Apple has just started to support agentic development with Xcode's MCP tooling and agent integrations in the IDE. That's a positive move, but it still assumes a heavyweight IDE-first workflow.

XcodeBuildMCP is IDE-agnostic. It supports developers who want the speed and flexibility of modern agentic tools while still building first-class Apple apps.

In practice, XcodeBuildMCP also provides a broader and more complete capability set, especially for runtime debugging, simulator interaction, and automation, than Apple's current MCP tooling.

Commitment to open source

Sentry is committed to open source and to the community that built XcodeBuildMCP.

In 2024, we helped launch the Open Source Pledge, a program that asks companies to contribute $2,000 per developer per year to the open source projects they depend on. We created the pledge because the world runs on open source software, but the people maintaining it are often unpaid and burned out.

The pledge is simple: pay the maintainers. We don't think it's the only way to give back, but direct funding is a good way to recognize the work maintainers do and the value they create.

Last year, Sentry gave $750,000 to open source maintainers, our fifth year in a row of direct funding. More than 25 companies have joined the pledge, collectively contributing over $6.8 million to open source since launch. The more who join, the more who will join, and the stronger the open source ecosystem will be.

XcodeBuildMCP joins that ecosystem as a maintained, supported project that developers can rely on.

Looking ahead

We're continuing to invest in mobile and in the tooling that accelerates modern software teams. XcodeBuildMCP is now part of that mission, and we're just getting started.

Size Analysis is generally available in Sentry

Tue, 10 Feb 2026 00:00:00 GMT

Sentry acquired Emerge Tools in May 2025 to bring best-in-class mobile tooling to dev teams. Today, we’re officially bringing Size Analysis - one of their flagship products - to all Sentry users, so you never have to worry about app size again.

Automated monitoring in your CI pipeline

The most common way app size grows is incrementally. Small changes add up over time and suddenly you’re getting warnings about being over the cellular download limit. Those small changes are easy to optimize as you make them, but try to address it a year later and suddenly it’s a more difficult task.

Size Analysis integrates into your CI workflow so you constantly have a pulse on your app size. Every build can be uploaded and diffed. Any time size changes, you won’t just see that it changed, you’ll see why it changed, and if there are any recommended fixes you can do to make it smaller.

Let’s look at a common scenario: adding an SDK.

Here’s our status check for adding Kingfisher. With Size Analysis, we immediately see:

The PR is adding ~500 kB to download size and ~1.5 MB to install size
The PR failed because we had a preconfigured threshold to fail any check where Install Size diff is more than 1 MB

We can double check our “Comparison Page” to confirm the diff is as expected and then approve the PR. From this page we are able to see the overall size change as well as both a tabular and visual view of every file that changed size.

In this case, it’s clear this is the intended diff so we can approve our status check and merge the PR 🎉.

Let’s look at another scenario: adding a new hero image.

We again see the overall size difference, but this time we also see two Insights. Not only were the images we added not optimized, they’re also being duplicated. Clicking in, we can see the exact files that can be optimized + how much space that would save.

Instead of adding 9 MB to the app, we can make this PR closer to 3 MB. Now imagine this insight is on every PR. Rather than having to spend cycles retroactively addressing size issues, Size Analysis prevents them from ever happening in the first place.

Whether you want to upload every single build or upload once a week with your release builds, Size Analysis will bring visibility and actionable insights to your app’s size.

Reducing your app’s size

Automated monitoring is critical to make sure your app size doesn’t creep up, but in reality, your app might already need slimming down. For every build that you upload, Size Analysis will give you a detailed breakdown of where size is coming from + how you can reduce its size.

Here we have the CalAI app (analyzed from a public App Store build). CalAI has an install size of ~250 MB. Looking at the Size Analysis, we can see very quickly that a large chunk of the app size (30%) is from duplicating an asset.car file twice.

We can open the Insight details to see a list of all insights:

Or we can even highlight all Insights on the treemap itself and hover over nodes to see how their size can be reduced:

Looking at a build’s details is great for seeing easy size win opportunities, but it also helps you understand where size is coming from. Below is the Chess.com app (also analyzed from a public App Store build):

We see a number of Insights for duplicate files and unnecessary binary data, but we can also see a fairly large openingbook.json node.

21 MB is a lot of JSON and something to be immediately suspicious of. Inspecting this file, we can see it’s actually a list of all the possible openings that Chess.com highlights (if you’ve ever played a game on Chess.com and seen the esoteric opening names, this is where it’s coming from).

The problem here is that the JSON is not being minified, so a simple minification takes it from 21 MB → 13 MB. Size could further be reduced by making this a SQLite file or more aggressively optimize by de-duping keys, similar to what we described here with localization size.

Chess JSON rabbit-hole aside, the point is that Size Analysis makes it obvious where your size is coming from and how you can reduce it. Applying Size Analysis wins is as easy as:

Automate monitoring so no extra cruft gets in the app
Pick off size reduction opportunities as you have bandwidth (or soon just as Seer 😉)
Track over time

Getting started with Size Analysis

Every Sentry plan includes 100 build uploads per monthly billing period (higher upload volumes are available via our Enterprise plan). You can view uploaded builds on the Releases page under Mobile Builds, and optionally add automated size change notifications to PRs. For the exact setup steps, see the Size Analysis docs.

If you don’t have a Sentry account, start one for free.

Watching everything is watching nothing: Sampling strategy for Sentry

Mon, 02 Feb 2026 00:00:00 GMT

TL;DR - Blanket sampling rates can be wasteful or inefficient. Capture 100% of the signal with less of the noise and fine-tune how you monitor your applications with custom sampling logic

In a high-traffic production environment, telemetry is your most direct link to the user experience. Every Span, Trace, Log, and Replay sent to Sentry gives you high-fidelity visibility into what is actually happening in production.

But to extract the most value out of that visibility, you have to know how to filter signal from noise. If you treat a routine "page load" on a stable legacy route with the same intensity as a critical experience, like a checkout flow, or a brand-new feature launch, you aren't optimizing the data you collect.

To build an observability strategy that survives scale and doesn’t break quotas, you need to move past "blanket sampling." You want to prioritize high-resolution data where things are critical or changing fast, and optimize your setup where the system is stable.

Why not sample 100% of everything?

You can!

And if your app is small or brand new, that might actually be the right plan. But as you scale, "100% of everything" usually stops being a practical option, for a couple reasons:

Signal-to-Noise: Telemetry data is more useful when you know what happened at a glance. Needing to parse through 1 million “user clicked button” spans to discover the 100 times users experienced issues during checkout isn’t efficient for you, for queries, or any LLMs that might be consuming the same information as us.
The Network Footprint: While the SDK is highly optimized, every interaction, every function call, it starts to add up. By sampling only what you need, performance stays high while still collecting valuable information.

The basic dials: Static sample rates

When you initialize Sentry, you get four main options for adjusting how much data you send. Understanding how these interact is the first step:

sampleRate: This is for errors. We almost always leave this at 1.0 because if something breaks, we want to know every single time.
tracesSampleRate: This provides a cross-section of your traffic. It’s your primary lever for managing the volume of performance data.
replaysSessionSampleRate: This records the whole session from the start. It's high-fidelity, so you usually only need a small percentage to see how the "average" user navigates.
replaysOnErrorSampleRate: This is a buffer. It only sends the replay if an error occurs, capturing the 60 seconds of activity leading up to the error.

Precision control: The `tracesSampler`

Traces are potentially the most important metric we have, responsible for monitoring performance, errors, and connecting all of our data together. In a production environment, you almost always want to sample 100% of traces. However, especially when dealing with very high-traffic applications, you don’t need to collect all of your traces if you trace strategically.

Instead of a blanket percentage, Sentry lets you pass a tracesSampler function to tracesSampleRate. This allows you to make a decision in real-time based on the context of the request.

What’s in the sampling context?

When a span starts, the sampler receives a samplingContext object. You’ll have this data automatically and can use it, along with anything else you may pass in, to decide if you should sample.

In your tracesSampler function, either call the context object or directly destructure the values you need, and provide a return value ranging from 0 to 1.

You can find a few useful example sampling functions in our docs.

Staying in sync with `inheritOrSampleWith`

If the backend has already decided to sample a trace, the frontend should usually follow suit. You can use the inheritOrSampleWith utility to handle this. Destructure it from the samplingContext and call it to inherit the backend sample, or fall back to another value.

Smart sampling with Session Replay

Traces tell you what happened and where (e.g., "The database was slow"). Replays show you how it happened (e.g., "The user clicked the button five times because the loading spinner didn't show up").

By default, Session Replay is configured to record a percentage of all user sessions, based on replaysSessionSampleRate. There is also a separate sample rate that runs in a buffer and only submits if the user encounters an error; we typically leave that one at 1.0 or a very high percentage.

While a typical Sentry plan comes with 5 million spans, we start with 50 Session Replays (though you can add additional of both). Not only do we have our plan quotas to worry about, recording a Session Replay is a little more taxing on our users.

While setting a sample rate is a good start, in a production application, we may want to be a bit more intentional with when we record. We may want to record certain parts of our app with greater frequency, like new features or parts of the critical experience flow.

While there isn't a replaysSampler yet, it is possible to manually initiate and manage replays using replay.start().

Custom `useSessionReplay` Hook

Session replays can be configured with an overall sample rate, but we can also choose to manually instrument Session Replay captures ourselves.

Let’s take a look at how we could build a custom React Hook to implement in our React/Next.js projects that will help us dynamically control how often we sample Session Replays per page.

First, remember to disable the replaysSessionSampleRate since we'll be implementing our own manually.

Then, add this wherever you store your hooks in your React app. We’ll use this in our app’s pages to define where we want to sample, how often, and we’ll even be able to inject some additional context.

This will let you dial in session replays to where you need them most, and even add important additional context.

It’s worth noting this method is not 100% free of downsides. This will only start recording after the component is mounted, so you may miss out on hydration issues that happen in the earliest part of the render. Though we may not be able to see that, we will capture it in Web Vitals.

What about Logs?

Logs are a recent addition to Sentry. If you enableLogs in your Sentry init config you can start sending logs to Sentry – either via the Sentry Logger from the SDK, or an integration like the Console Logging Integration.

Sentry receives 100% of logs by default if the integration is enabled. However, in high-traffic environments, you should filter logs at the source, using Sentry’s beforeSendLog or another logging tool, like LogTape and structured logging.

We recently talked about using LogTape with the Sentry sink to elevate how we approach logging in our production apps.

At the most basic level, we can limit what logs are sent, per sink, based on the “severity” level. We may instrument our app with debug logs, but at scale, these may be noisy and eat into our quotas. Instead, we can decide to filter out the lowest levels of logs by configuring lowestLevel.

With well-planned, structured logging, we can easily filter on specific data attributes. This is useful not only for limiting and processing what data we send (and where) for noise to signal reasons, but also for data scrubbing.

Using LogTape filters we can instrument our own filtering logic, including even our own built-in sampling logic if we wished.

Summary: Sampling telemetry at scale

Setting up Sentry for the first time is simple: instrument your SDK, set your sample rates to 100%, and wait to start seeing all your errors, performance data, logs, session replays, and more coming in. But, as traffic ramps up and monitoring priorities change, you ideally want to optimize out the noise from the signal, and focus attention where it is needed.

Traces: Traces map and connect events in your apps. While you typically want to record most if not all of your traces, with enough traffic, it makes sense to prioritize high-impact targets.
Session Replays: Replays are your highest-fidelity tool, but they carry the most weight. Instead of a blanket percentage, use replay.start() to trigger recordings only during critical user flows, like at checkout, or where new features are enabled, and the visual context is highly valuable.
Logs: Use beforeSendLog to filter by severity or custom metadata. Stop sending "Info" logs for every routine event; adopt structured logging so that when a log does hit Sentry, it’s already formatted to be searchable and high-signal.

New to Sentry? Sign up get started, or check out our quickstart guides for Logs and Session Replay.

Less code, faster builds, same telemetry: Turbopack support for the Next.js SDK

Thu, 29 Jan 2026 00:00:00 GMT

TL;DR - Turbopack became the default in Next.js, so we reworked our SDK to stop depending on bundlers. The result is less code, faster builds, and the same telemetry. This blog explains how we got there.

You know the feeling when you spend years building tooling that supports something and all of a sudden that something becomes deprecated and you have to rethink your full approach?

And no, this isn’t a post about Ralph Wiggum, the recursive agent practice that we all as a community decided was okay to name that way and roll with it.

This is about Next.js rolling out Turbopack, deprecating Webpack (as of Next.js v16 Turbopack is the default) and us rethinking our telemetry approach in the SDK.

What we were doing before

When you ran next build, our Webpack loader intercepted every page, API route, middleware, and server component. It would:

Parse your file to determine its type
Bundle it with a Sentry wrapper template using Rollup
Replace your original code with the instrumented version

This worked. It also required maintaining six different wrapper templates, a 360-line webpack loader, and roughly 1,667 lines of instrumentation code. Every new Next.js feature — server components, route handlers, the App Router — meant writing another template and hoping Webpack's internals hadn't changed since last time we looked.

We were building a parallel universe where every file had a Sentry-wrapped doppelgänger. It's the kind of architecture that works until it doesn't, and when it doesn't, good luck figuring out which layer broke.

What we do now

Next.js has built-in OpenTelemetry instrumentation. It emits spans for every request, middleware execution, and render operation — complete with route information. Instead of wrapping your code, we listen.

The snippet above is the clean version. In reality, we overwrite the standard Next.js OTel config with Sentry-specific parts (span processors, context manager, etc.) and customize our HTTP integration to disable incoming Next.js-generated spans so we can enrich them ourselves. Still simpler than six Rollup templates.

The Turbopack-specific code is about 164 lines. That's a 10x reduction from the Webpack approach, and most of those lines are config handling, not instrumentation logic.

What this actually means for your builds

Charly, an engineer on our Next.js SDK team, ran a test against the Sentry Changelog repo to see the difference:

The SDK no longer runs Rollup on every file in your application during compilation. If you've ever wondered why next build was taking a while, some of that was us. (Sorry.)

The SDK automatically detects whether you're using Turbopack or Webpack and adjusts. If you're on Next.js 15.4.1 or later, Turbopack just works. The tracing data you see in Sentry looks the same — route handlers, middleware, server components, data fetching. All still there.

What changes

Some Webpack configuration options no longer apply when using Turbopack:

If you were excluding specific routes from instrumentation, you'll need to filter them via Sentry's beforeSendTransaction hook instead. The SDK relies on Next.js's OpenTelemetry instrumentation, so there's no build-time wrapping to opt out of.

Server Actions still require manual instrumentation:

Server Actions don't emit OTel spans we can hook into. We're watching Next.js development here — if they expose the telemetry, we'll add automatic instrumentation.

Why this matters beyond our codebase

Instead of every APM vendor maintaining their own build plugins, loaders, and bundler integrations, frameworks are adopting OpenTelemetry as a standard telemetry interface. Next.js emits spans. We consume them. The framework handles the "how," we handle the "where it goes."

This is where framework instrumentation is heading. We just got there by deleting code instead of writing more of it.

Requirements

Next.js 15.4.1+ for Turbopack production builds
Next.js 15.6+ for native Debug IDs (improves source map resolution)
No changes to your instrumentation.ts or instrumentation-client.ts files

Next.js 16 makes Turbopack the default bundler and the SDK is ready for it.

The 15-month journey from "Turbopack: unsupported" to "Turbopack: default" involved 19 PRs, a complete architectural rethink, and the realization that the best way to support a new bundler was to stop depending on bundlers altogether. That approach now powers our Next.js SDK.

Log Drains now available: Bringing your platform logs directly into Sentry

Wed, 28 Jan 2026 08:00:00 GMT

Sentry now supports log drains, making it easy to forward logs into Sentry without any application code changes or manual project-key lookups needed. If your logs already exist somewhere else, you can now see them alongside errors and traces in Sentry, no code changes required.

Already want to get started? The quickstart guide is one click away.

Get all your logs in one place connected to issue context

When we made logs generally available in Sentry back in September 2025, the goal was to enable developers to view logs, traces, errors, and replays in a single platform. And the feedback was largely about having the right logs attached to the right issues by default.

Now with log drains, your platform logs (and traces) automatically flow into Sentry so the same “extra set of eyes” extends to platform-level events outside your application code.

If you are thinking “just show me an example,” watch our DevEx team walk about Vercel logs in Sentry.

By pulling platform logs into the same place as your application errors and traces, teams get a complete picture of how systems behave across builds, deploys, edge runtimes, databases, and auth layers—without running additional agents or touching application code.

Instead of jumping between dashboards or losing logs to short retention windows, engineers can investigate issues end-to-end in Sentry.

Get started with 5GB of logs included on every plan (with additional usage at $0.50 per GB).

How are teams already using drains?

Debugging a Vercel deployment without leaving Sentry

After a deploy, an ecommerce team sees a spike in client-side failures in Sentry. Browser events and logs captured by the Sentry SDK, like ui.render_failed and api.fetch_failed, cluster around the billing page route=/settings/billing, mostly affecting Safari users in one region. The SDK gives them the who and where, with route, user agent, region, and release already attached. And because they add vercel.deployment_id as a custom tag in Sentry, it’s easy to see the spike lines up with a single deploy rather than a broader issue.

From there, the team pivots to Vercel logs in Sentry, filtering to log drain events using origin:auto.log_drain.vercel for the same time window. Grouping runtime logs by the resolved function path vercel.path and where the code actually ran vercel.execution_region reveals a clear hotspot. Requests to /api/billing/subscription are returning 5xx responses, concentrated in a single region.

Now the same failure is visible from two useful angles. The SDK view shows what went wrong inside the application, with stack traces and app context. The Vercel log drain view adds the surrounding runtime details like request IDs, duration, memory usage, and stderr output. Switching between the two makes it easier to understand not just the error, but how it behaved in production.

Build logs for the deploy using vercel.source:build are clean, confirming the deploy itself succeeded. Looking next at Vercel firewall logs using vercel.source:firewall fills in the final piece. There is a spike in deny actions for the same route at the edge vercel.proxy.path in the affected region. These platform signals explain why some requests never reach application code.

Putting it all together, the team sees the billing page fails because its backing API intermittently fails and in some cases is blocked within a specific region. They add log-based alerts on runtime 5xxs and firewall actions, grouped by path and region, so future regressions are immediately tied back to a specific deploy and blast radius.

Debugging Supabase auth and database issues

A team using Supabase for Postgres relied on Sentry SDKs in their application services, but had limited visibility into issues originating inside Supabase itself. Database errors were only available in the Supabase dashboard with limited retention, making post-incident investigation difficult.

By enabling a Supabase Log Drain, the team forwarded Supabase Postgres logs into Sentry without changing application code. This surfaced database activity in the same place as their application telemetry, searchable with queries like:

service:supabase AND message:*error*

In one incident, an increase in login failures lined up with Supabase database logs showing repeated errors related to expired tokens (message:*JWT*expired*). With those logs retained in Sentry, the team quickly identified a misconfigured token lifetime rather than an application issue, avoided unnecessary code changes, and resolved the problem directly in Supabase.

Bringing Cloudflare Worker logs into Sentry

A team running an API behind Cloudflare Workers used Sentry SDKs in their core services, but Worker behavior remained a blind spot. Requests were occasionally failing due to routing, caching, or request-size issues, yet Cloudflare Worker logs only lived in the Cloudflare dashboard and were often unavailable during incident reviews.

After enabling a Cloudflare Log Drain, the team streamed Cloudflare Worker application logs into Sentry without deploying agents or modifying application code. They were able to search Worker errors using queries like:

service:cloudflare AND message:*error*

During one incident, a spike in 4xx errors aligned with Worker logs showing repeated request-size rejections (message:*request body too large*) from a single region. With these logs visible in Sentry, the team identified the issue as an edge configuration problem rather than a backend failure, avoided unnecessary service changes, and fixed the issue directly in Cloudflare.

Ready to get started?

Logs are available for all plans. Every plan includes 5GB of logs, with additional usage at $0.50 per GB and a 30-day log lookback (plus an unlimited 14-day trial you can start anytime). For setup details, choose our logs and log drains documentation or choose your platform below:

Platform drains

Forwarders

Once enabled, logs typically show up within seconds and are automatically associated with related errors and traces—no extra configuration required.

Not a Sentry User? Start your free trial.

Seer: debug with AI at every stage of development

Tue, 27 Jan 2026 00:00:00 GMT

When we launched Seer, our AI debugging agent, we built it on a core belief: production context is essential for understanding the complex failure modes of real-world software. Seer uses the detailed telemetry that Sentry collects (errors, spans, logs, metrics, and more) to accurately root cause and fix bugs. Because this telemetry is trace-connected, Seer can deterministically traverse all the data relevant to a problem rather than relying exclusively on imprecise time-range searches.

Coding agents can find some bugs by reading source code, but others are only reliably identifiable by observing runtime behavior. In distributed systems, failures often cross network boundaries: an unhealthy service can trigger timeouts or cascading failures elsewhere, and some issues only occur under load. The same applies to understanding performance characteristics. A p95 latency spike might stem from lock contention, a saturated connection pool, or other root causes not obvious from the code. Runtime context provides the evidence Seer needs to accurately diagnose and fix these real-world problems.

While fixing bugs in production will always be a critical use case, the best bugs are those you never ship.

Today, we're shifting left and expanding Seer's capabilities to help you debug during local development and code review, alongside a new flat price for unlimited use.

Debug as you build locally

Bugs are easiest to fix at the moment they're introduced. The Sentry MCP server connects your local coding agent to a powerful debugging feedback loop, enabling you to catch and resolve issues during development rather than in code review or production. As you reproduce bugs locally, telemetry flows from your application to Sentry, where the agent can access raw events for context or invoke Seer to run a full root cause analysis. Your coding agent gets everything it needs to generate a patch before the code leaves your local environment.

Code review that catches real defects

Still, no local environment catches everything. For bugs that slip through, Seer steps in at code review time, identifying issues in your pull request before they're merged. Seer focuses on finding real bugs that risk breaking production, not low-signal suggestions or stylistic nitpicks. Catching these defects at review time means fewer incidents, faster releases, and less time spent debugging in production.

If you already use Seer, set up code review by installing the GitHub integration and connecting GitHub repos in Seer Settings.

Automate root cause analysis in production

Even with these safeguards, some bugs will reach production. When they do, Seer identifies the most actionable issues and automatically uses your runtime telemetry to determine the root cause in the background. When Seer is highly confident that an issue is actionable, it can go further and generate code changes to fix the bug, or delegate to coding agents like Cursor to implement the fix on your behalf.

Investigate the unknown

Seer's automated root cause analysis works well when Sentry has already identified an issue. But sometimes the problem isn't a bug that Sentry has flagged. A customer reports that something feels off, or a dashboard shows a metric trending in the wrong direction. For these less structured investigations, we're building a new experimental capability: the ability to ask Seer open-ended questions about your data or anything you see across Sentry. Describe what you're observing, and Seer will query across your telemetry to surface relevant patterns and anomalies, helping you turn your hunch into an actionable root cause.

This feature is currently in development, but it’s available in early preview for select Seer customers. Join this GitHub conversation to request access.

Unlimited debugging for one flat price

Along with these expanded capabilities, we've simplified pricing. Seer is now $40 per active contributor per month, with unlimited use. There's no need to manage seats or worry about overages; just connect the GitHub repos you want Seer to cover, and it will keep track of contributors automatically. Anyone who creates at least 2 pull requests in a connected repository during the month counts as an active contributor.

Debugging doesn't happen at a single point in your workflow, and neither should your tools. Seer meets you where you are: in your development environment, in code review, and in production. Existing Sentry customers who use GitHub or GitHub Enterprise can activate a 14-day free trial in settings. New to Sentry? Here's how to get started.

Monitoring microservices and distributed systems with Sentry

Thu, 22 Jan 2026 01:00:00 GMT

If you’ve ever tried to debug a request that touched five services, a queue, and a database you don’t own, you already know why monitoring distributed systems is hard.

Logs live in different places, requests disappear halfway through a flow, and when something breaks in production, you’re reconstructing what happened from fragments.

Microservices make this worse by design. A single request fans out across small, independently deployed services, often communicating asynchronously. And the moment a request leaves a service you control, your visibility usually drops off a cliff.

This guide shows how to use Sentry tracing and logging to follow a request end to end, so you can answer the questions that usually take far too long in production:

Where did this request actually go?
Which service slowed it down or failed?
How do I see that without stitching logs together by hand?

Prerequisites

You need no experience with microservices to understand this article. Experience writing a web service is useful.

To follow the tutorial, you need:

Docker: We’ll use Docker to run the example app. Docker guarantees that the app runs on any operating system, without needing to install any programming language versions, in a secure sandbox safely isolated from your personal files.
A Sentry account: You need a Sentry account if you want to connect the example application to one of your Sentry projects.

And to make things a little bit easier, actions you need to perform are marked with ▶️.

The example case study

This example is intentionally simple. Real systems look a bit busier.

But the failure modes are the same: requests fan out, work happens asynchronously, and when something breaks, the original context is usually gone.

Let’s review how and why a microservice design works using a simple example. Imagine you have a website where a user can place an order for an item that needs to be made. The item could be anything from a physical 3D-printed object to a digital tax certificate.

You currently have a monolithic web server that handles the entire process and stores all data in one database. This is its design:

You have different teams working on the website, order management, and factory production of the items — and they each want to deploy improvements to their code and database tables independently, without breaking the rest of the system.

So you decide to separate your single service and database into three separate services (web, order, and factory). Your system now looks like this:

Each service knows the address (URL) of the other services. So if the order service wants the factory service to start making an item, the order service calls the factory service using an HTTP POST request.

Then the website team gets upset that the order service isn’t responding to orders fast enough, and is blocking the website from responding to user requests.

So instead of letting services call each other directly and synchronously, you decide to use a message queue, like RabbitMQ, for all communication. To demonstrate how a message queue works, consider an example: The web server places a “create order” message on the order service’s queue without waiting for a response. The order service takes the message off the queue when the service is ready, and puts a response message on the web service’s queue when the order is ready for collection. No service needs to know the address or status of any other service — each service talks only to RabbitMQ.

Your system now looks like this:

This design now meets the microservice architecture criteria. Each service is small and focused, independently deployable by having a separate database and a separate Git repository, and autonomous by using an asynchronous message queue.

Even more flexible designs

You can make the design even more flexible. For example, your factory and order teams realize they need to start additional instances of their services when the number of requests increases. So you might have three factory services running simultaneously, all taking orders from the queue and writing to the same shared factory database.

Then, you need a central repository of URLs for each system component, like the order database and RabbitMQ, so that each new service knows where to find everything as containers start and stop, and URLs and ports change. To support this service discovery, you might use a simple key-value store in a container, like etcd, or you might want something more powerful, like Consul, or even a container orchestrator like Kubernetes.

The example app

In the GitHub repository that comes with this guide, we’ve created a minimalist microservice app that runs the services discussed in the case study.

▶️ Clone, or download and unzip, the repository onto your computer.

There are two folders in the repository: withSentry and withoutSentry. This guide runs the withSentry app to demonstrate monitoring, but if you want to see an even simpler microservice design without any monitoring, you can look at the code in withoutSentry.

Below is a simplified diagram of the design used in both folders. Each component in the backend runs in a separate Docker container, configured by docker-compose.yaml. There are:

Three Node.js services (3_web.ts, 4_order.ts, 5_factory.ts)
Three MongoDB databases, which you can see at the top of the Docker Compose file (msWebDb, msOrderDb, and msFactoryDb)
The RabbitMQ software, which you can see in the middle of the Docker Compose file

Using Node.js and MongoDB keeps this demonstration project as simple as possible, as Node.js code doesn’t need compilation (like Go) and MongoDB doesn’t need table creation scripts (like PostgreSQL).

Configure the app to use Sentry Tracing

Now that you’ve downloaded the app, let’s configure it to send traces to Sentry.

▶️ Open the Sentry web interface and use the sidebar to navigate to Settings —> Projects.

▶️ Select the project you want to use for this test. If you have only a real production project available, first create a Node.js project for the demo app, then select it.

The sidebar contents will change to show the project details.

▶️ In the sidebar, navigate to Client Keys (DSN) and copy your DSN.

▶️ In your withSentry project directory, open the .env file and enter the copied DSN as the value of the SENTRY_DSN environment variable.

This setting instructs all services in the app to use your Sentry project. Docker Compose pulls the SENTRY_DSN value from .env and sends it to the containers that have the SENTRY_DSN environment variable.

▶️ In Sentry, navigate to Loader Script at the bottom of the sidebar and copy the script shown at the top of the page

▶️ Open withSentry/index.html and replace the script line near the top of the file (below <head>) with the copied loader script.

This setting links the app’s frontend webpage to your Sentry project. If you want to further configure an app, for example, to send only a fraction of traces to Sentry, refer to the Loader Script documentation.

Run the app

Configuration is complete. Now you can run the app and see traces arrive in Sentry.

▶️ Open a terminal (command prompt) in the withSentry folder, and run the following command:

docker compose up

If you run docker ps in another terminal, all containers should show as healthy after ten seconds to a couple of minutes. Docker image and npm package downloads might take a while.

Note: The container names start with ms, for microservice, to separate them clearly from any other containers you might run.

▶️ In your web browser, open the app at http://localhost:8006.

▶️ Disable any advertisement or tracker blockers and reload the page to ensure that Sentry is available.

Unblock Sentry

A new UUID is set in the Create order line whenever you refresh the page, but you can enter your own order name, like alice or 2.

▶️ Click Submit to start an order.

Notice the order ID is set in the Check order line, and the Order status updates with a single call to check on the web service.

▶️ Click Check repeatedly until the Order status changes to finished in about ten seconds.

The microservice website

Here’s what happened:

The webpage called the web service, which created the order in the web database.
The web service then sent the order ID to the order service via a message on RabbitMQ.
The order service then received, saved, and passed the order to the factory service.
The factory service received the order, waited five to ten seconds, then passed a message to RabbitMQ saying the item was made.
The order service passed the status update back to the web service.
By clicking the Check button, you requested the status of the order from the web service, which looked in the web database.

Let’s see if that process is clearly shown in Sentry.

▶️ Navigate to Explore —> Traces in the Sentry sidebar and ensure your test project is selected at the top of the traces page.

If you see traces, jump ahead to the next section on understanding tracing.

If you don’t see any traces after a minute, check for app configuration problems by following the troubleshooting instructions below. If it’s a new Sentry project, first skip through the steps in the Set up the Sentry SDK section using the Next button on each step and then, lastly, click the Take me to my trace button.

Troubleshooting

The application needs six free ports on your computer: 8000 to 8006. In the unlikely event that any other application uses them, you should stop that application.

▶️ Open a new terminal and run the code below to see the service logs.

The output should be similar to the following:

If you notice any errors, fix them first, before trying to see traces on Sentry. The most likely problem is that your project DSN in the .env file doesn’t match the one in Sentry. Otherwise, it’s likely that npm couldn’t connect to the internet to download packages – in which case, try disabling any firewalls or VPNs temporarily and restarting Docker in the project folder with this command:

You can also check the contents of the databases using the commands below:

Understand Sentry Tracing and Logs

▶️ At the bottom of the Traces page, click any of the span IDs.

You should see a trace similar to the one below. Each trace represents a connected series of operations and actions, and is made up of spans. There are red annotations to show you which span corresponds to which service.

Distributed trace

This is the moment distributed tracing pays off: every service call shows up in one place. Sentry passes the trace ID with every call made by a service, and so can follow the flow of service and database calls (even through RabbitMQ messages) from the website all the way down to the factory and back again. You can see this flow by reading down the call stack on the left of the page.

The span from the webpage shows everything from the page load to individual button clicks. While RabbitMQ itself isn’t instrumented with Sentry, the JavaScript that calls it is, so you can see all messages sent to and received from RabbitMQ. Similarly, MongoDB isn’t instrumented with Sentry, but calls to it are.

If you look at a database call, you can see that the parameters aren’t recorded. For example:

This is called query scrubbing. Sentry uses it to prevent sensitive data, like credit card numbers or password hashes, from being recorded. If you need the exact query details, Sentry Logs can capture them instead.

So what is this trace useful for?

First, it shows whether the system is behaving as expected. You can see if the control flow is correct, whether messages are duplicated, or if failures or database writes are missing.

Once the logic looks right, you can look at performance. How long does the full order take? Are there slow or inconsistent requests? Which service is responsible?

And when a user has a question, you can find the trace for their order ID and see exactly what happened.

In the example above, the flow jumps back out of the indentation near the bottom. That’s when the factory waits a few seconds to “manufacture” the item before sending a new message to the queue:

Real systems don’t respond in seconds. Updates often arrive long after the original trace ends. The way to connect them is with a shared identifier.

Here, that identifier is the order ID. Because it’s attached to spans across services, you can search for it in Sentry and see the entire lifecycle in one place.

▶️ Copy your order ID from the textbox on the app webpage to the filter in the Sentry Traces page, as shown below. (You cannot type is in the filter textbox. You have to first type orderId, then click for more options.)

Tracing an order ID

Click the Edit Table button on the right to include any attributes you’re curious about in the filter results.

Logs

This article focuses on distributed tracing, but Sentry also supports standard monitoring tasks like capturing errors and exceptions with Sentry.captureException(e).

Because an exception stack trace doesn’t include cross-service context, it’s important to attach an identifier — like orderId — before capturing the error. One way to do that is with a breadcrumb.

A breadcrumb is lightweight context that’s recorded locally and only sent to Sentry if an event, such as an error, occurs. For example, when the factory starts creating an item, you might add:

If that function later throws an error and you capture it, the breadcrumb appears alongside the stack trace in Sentry.

Structured logs are similar, but more powerful. Instead of a single text message, they record key-value pairs, which makes filtering and searching easier in the dashboard. Unlike breadcrumbs, structured logs are sent immediately and aren’t tied to an error.

The microservices example uses logs alongside traces to provide this additional context.

▶️ In the Sentry sidebar, navigate to Explore —> Logs.

Distributed logs

In the screenshot above, the table includes two attributes added to the structured log: orderId and service. You can see each service logging when it receives a message from RabbitMQ.

In this simplified example, traces and logs look similar because both show the flow of an order through the system. In a real application, they serve different purposes.

Traces show how execution moves between components. Logs let you record whatever context you need inside your own business logic. You can add logs at specific steps, adjust them temporarily while debugging, and remove them when you’re done.

Logs also support severity levels (trace, debug, info, warn, error, and fatal) which makes them useful across development, testing, and production environments. Read the guide to setting up logs in Node.js to learn more.

How to monitor a distributed app with Sentry

Now that you’ve seen what monitoring looks like in Sentry, let’s add it to your app. The examples in this section work in any Node.js application, not just microservices. From Sentry’s point of view, there’s no difference, and the same ideas apply in other languages like Python or .NET. Only the syntax changes.

Monitor a webpage

The loader script import you added to index.html in the configuration section is all you need to start automatic monitoring of any webpage. It looked like this (remember to change [YOUR_ID]):

▶️ If you need to configure Sentry differently from the defaults in this script, add a Sentry.init() call to create a custom configuration.

You can set your DSN inside the init function instead of hardcoding it into the script import URL above. You don’t have to hide your DSN from the public, as cases of abuse are very rare and Sentry can handle them.

Sentry automatically collects traces for page navigation but not for fetch requests.

▶️ To record detailed information (such as the order ID), you need to manually instrument your HTTP calls.

The following Sentry.startSpan code is from the create order function in index.html:

The startSpan() function manually creates a span that records any call made within it. In this case, it records a call to fetch('http://localhost:8006/order'). Only the name parameter is mandatory, but the code includes the order ID as an attribute, and later adds the response status code as an attribute too, after the call completes.

Monitor a web service

▶️ To instrument a web service automatically, you need only import the Sentry configuration outside your code file.

This import is shown in the following Docker Compose file command:

The file 1_sentry.ts configures Sentry. It contains the following content:

Without your DSN, Sentry will not work. Without enableLogs, logs will not be sent to Sentry.

Sentry automatically enables several integrations (monitoring plugins) by default, including MongoDB and RabbitMQ.

▶️ If your app uses other tools, look at the integration documentation to learn how to enable them.

A single configuration file is all you need for Sentry to automatically monitor your service. However, if you want to add custom attributes, like orderId, across services and to use logging, you need to import the Sentry library in your code and add some manual instrumentation too.

▶️ Import Sentry using the following line:

▶️ To send a log entry, you can use a single line:

This call has a text message, and two attributes sent as JSON.

▶️ To add an attribute to a span, use the following code:

This line adds an attribute to the span created by Sentry’s automatic instrumentation.

If you examine all the spans in the trace in the Sentry website, you may notice that some spans don’t have order ID attributes. If you need an ID attribute and Sentry hasn’t automatically created a span for you to attach to, you need to create a span manually using startSpan(), as the website code does.

Tips for monitoring microservices and distributed systems

Here’s the short version:

Sentry automatically creates spans for most operations without manual instrumentation.
To add logs or custom attributes, you’ll need to instrument those explicitly.
For tools without built-in integrations (like some message queues or databases), you’ll need to enable integrations or add manual instrumentation.
Because distributed systems don’t have a single call stack, you need a shared identifier, like orderId, to link asynchronous work across services. UUIDs work well, as long as they’re easy to search for later.

Monitoring also looks different once services are independent. In this guide, all traces go to a single Sentry project. In practice, teams often use separate projects so they can own their own alerts, data, and workflows. This improves separation of concerns but adds operational complexity. Administrators can still investigate traces across projects when needed.

That independence means teams also need to agree on shared conventions. Centralized configuration and consistent message formats make it much easier to follow a request across services when something breaks.

Finally, microservices generate a lot of traffic. Start with a low trace sampling rate, around 10%, to understand system behavior without overwhelming yourself. As your application scales, keep an eye on service load and request latency so you know when it’s time to scale up.

Green dashboards, red flags

Wed, 21 Jan 2026 00:00:00 GMT

A VP of Engineering (from a company I’m not allowed to name) told me recently: "You helped us find and fix real user-facing issues. Now we need to convince our CTO why that matters more than the standard SLO’s and systems."

Here's the thing: your CTO is not wrong in measuring the systems and basic uptime. That’s the baseline though. They’re all trying to watch everything, but they’re seeing nothing as it relates to users.

The traditional monitoring trap

Uptime looks great. Latency is within SLOs. Error budgets are fine. Dashboards are green.

And yet: your users are still failing. Not because your system is down. Your system is fine. But somewhere between "user clicks button" and "user gets what they wanted," something broke. Silently. No alert. No threshold crossed. Just a user who gave up and left.

Code breaks. That's not the scandal. The scandal is found out three weeks later when it’s escalated by the sales team because a big customer is frustrated and leaving.

Money moments

Every product has a handful of “money moments” — the specific hyper-crucial parts of your product where the user succeeds or you lose money. Not "is the API up." Not "did the page load." The actual thing they came to do.

Just a few examples we’ve heard of recently:

A retailer hit perfect uptime through Black Friday, but… Conversion dropped 12%. The money moment — a user completing checkout — was broken for anyone with a specific browser extension. No server errors. No alerts. Three weeks of lost revenue. The fix took an hour. Realizing the issue existed took forever.

A payments company met every SLO, but… Customers complained about "random" failures. The money moment — a transfer that actually completes and confirms — was failing intermittently for cross-border payments. A timeout edge case; Dashboards only showed averages. Users felt pain. Six lines of code, buried under months of noise.

A B2B platform looked healthy by every metric, but… the money moment — a new customer hitting their "aha" moment — was broken for enterprise accounts with a specific config. Sales found it before monitoring did. Dashboards all said the system was "up" but the product was broken.

Same pattern. Every time.

You're measuring the wrong thing

Here's the difference:

What most teams measure: Is every service running? Are metrics within thresholds? Is the system healthy?

What actually matters: Did the user succeed? If not, what code broke? How fast can we fix it?

One is horizontal. Watch everything, hope you catch something.

The other is vertical. Follow the money moment end-to-end. Know immediately when it breaks. Trace it to the release. Fix it.

You can do both. But if your dashboards are green yet users are failing, you know which one you're missing.

What to actually do

This isn't complicated.

Name your money moments. Not fifty different flows. Identify the three to five that determine if your product works — the ones that matter to your user, and whether or not they can do what they came to do. What are the moments where users succeed or you lose them?
Monitor them by segment. Not averages. By customer tier, by region, by device, by release. The bug that breaks your biggest customer doesn't show up in aggregate metrics.
Tie them to releases. When a money moment fails, the first question is "what changed?" If you can't answer that in minutes, you're flying with your eyes closed.
Measure time-to-fix, not time-to-alert. Nobody cares how fast your dashboards turned red. They care how fast you found the broken code and shipped the fix.

This isn't theory

Teams that monitor their money moments instead of just their dashboards keep finding the same thing.

One SaaS company had three APM tools and zero visibility into actual user flows. A dev spotted a call firing eight times instead of once buried across async queues, messaging layers, and persistence. Once they could trace the money moment end-to-end, they fixed it in minutes. Before? That would have taken days of log spelunking.
An influencer marketing platform found a 50-second page load that only impacted power users, and kept them from accessing one of the most critical workflows. By tracing the user flow instead of just watching service health, they identified the broken release in five minutes and had it fixed within the hour.
A language learning app with 200+ microservices cut debugging time by 12x. One engineer spotted bot activity and confirmed it in under ten minutes — before it could slow the site to a halt and lose them users. "This has saved years of my life."
One of the world’s biggest AI research companies learned to better detect otherwise-quiet crash loops during model training, dramatically speeding up the process of evolving from model to model. Monitoring the actual user experience instead of just infrastructure metrics made the difference.

Same pattern every time: the fix was straightforward once they could see where the money moment broke.

The bottom line

Code breaks. Always has. Always will.

The teams that win aren't the ones with the greenest dashboards. They're the ones who find the broken stuff fast and fix it before users notice.

Your uptime is not your product. Users succeeding is your product. Everything else is noise.

Paginating large datasets in production: Why OFFSET fails and cursors win

Thu, 15 Jan 2026 00:00:00 GMT

The things that separate an MVP from a production-ready app are polish, final touches, and the Pareto ‘last 20%’ of work. Many of the bugs, edge cases, and performance issues will come to the surface after you launch, when the user stampede puts a serious strain on your application. If you’re reading this, you’re probably sitting on the 80% mark, ready to tackle the rest.

In this article, we’ll look at the case of how to paginate large datasets at scale, where things can go wrong, and how database indexes shape the outcome.

This article is part of a series of common pain points when bringing an MVP to production:

Paginating Large Datasets in Production: Why OFFSET Fails and Cursors Win (this one)
AI-driven caching strategies and instrumentation

The pain (post-launch reality)

Everything was fine during testing, but after a while pages started taking seconds to load. The smart move is to have Sentry set up before you launch. Even if you don’t do any custom instrumentation, Sentry will let you know when your database queries get slow:

The screenshot shows a Slow DB Query issue in Sentry. Because I used Drizzle ORM with node-postgres, Sentry automatically instrumented all database queries for me. With that telemetry data, Sentry is able to surface slow database queries.

If we scroll a bit lower we’ll see the request info:

From this, we can see:

The query was invoked in the GET /admin/tickets request
The query contains OFFSET so it’s an offset-based pagination query
The query was invoked on the page 321
The query took 3.85s
Seer guessed that it’s likely a missing index

Let’s confirm that we’re really missing indexes:

Seer was right! The combination of a large dataset, lack of database indexes, and an offset-based pagination is amplifying this issue. Because there’s no database index, and the pagination is offset-based, navigating to higher-numbered pages like in this case 321 forces the database to scan 321 × page_size rows. That’s where the slowdown happens.

The solution (indexes and cursors)

We can fix this issue by refactoring the pagination from offset-based to cursor-based, and for that we’ll also need to add a database index.

Database indexes

Database indexes are lookup structures that let the database find rows without scanning the whole table. Think of them as a sorted map the engine can jump through quickly instead of going through the data row by row. It’s not free - you pay for extra disk (not a lot really) and write cost (indexes need to be updated after every write), but reads become dramatically faster, especially at scale.

Cursor-based pagination

Offset-based pagination forces the engine to scan and skip N rows each time, which gets slower as N increases. Cursor-based pagination on the other hand uses a stable value from the last retrieved row (the “cursor”) to fetch the next page, letting the database jump directly to where it left off. The cursor is usually an indexed column, like created_at, or id, or a combination of both. Cursor-based pagination wins by a landslide in real-world performance and stability.

Applying the fix

Let’s create a composite index that combines the created_at and the id:

We’re adding CONCURRENTLY to avoid write locks, and IF NOT EXISTS to keep migrations idempotent.

Now let’s modify our SQL to use the id and created_at derived from the cursor to fetch the next page:

Now since we need to calculate and pass the cursor when paginating, our URLs will change from: ?page=321 to ?cursor={nextCursor}&prevCursor={prevCursor}. Our backend will parse the nextCursor, extract the created_at and id from it, and properly construct the WHERE clause we see in the SQL above. The prevCursor is just for navigating to the previous page.

The Proof (watching duration drop)

A few minutes after applying the changes, it’s time to check the results. We’ll go in Sentry > Insights > Backend > Queries, click on the “+” button to add a filter, select “Spans > sentry.normalized_description”, add it, and modify it to contain the start of our query: SELECT … FROM tickets LEFT JOIN. This filter will capture both the old offset-based query and the new one. This will update the charts below, and if we look at the “Average Duration” chart we’ll easily spot when we deployed the fix.

It’s easy to spot. And no, the chart doesn’t zero out. It dropped from ~8s to ~13ms. Mind you, this is running locally, but even in production it’s still going to be significantly faster.

That’s the effect of having database indexes and refactoring the pagination from offset-based to cursor-based. Our database doesn’t need to scan through thousands or millions of rows each time we want to navigate to a page. The index allows it to jump to a specific row instead of “walking” to it, and the cursor tells it which row it needs to jump to. Efficient!

The takeaway (what production actually demands)

This wasn’t a fancy optimization. No exotic data structures. No caching layer. No AI. Just respecting how databases work when the testing data is gone and reality shows up.

Offset-based pagination plus missing indexes is a tax you don’t notice until traffic forces you to pay it. The bill arrives late, compounds fast, and lands directly on user experience. Cursor-based pagination with proper indexes flips the cost model entirely: predictable, stable, and boring in the best possible way.

The important part isn’t that the query went from seconds to milliseconds. It’s that the shape of the performance curve changed. Offset pagination degrades linearly as your data grows. Cursor-based pagination stays flat. Flat curves are how systems survive growth.

Sentry’s role here isn’t just “finding a slow query.” It closes the feedback loop between theory and reality. You make a change, deploy it, and immediately see whether the system agrees with your mental model. In this case, the database nodded enthusiastically.

Production readiness lives in these details. Indexes. Access patterns. Measurement. Not glamorous, but decisive. MVPs prove ideas. Production systems prove discipline.

Logging in React Native with Sentry

Wed, 14 Jan 2026 00:00:00 GMT

Logs are often the first place dev teams look when they investigate an issue. But logs are often added as an afterthought, and developers struggle with the balance of logging too much or too little.

As a seasoned developer, you may remember a time when you were asked to investigate an issue and then handed a 200 MB plaintext log file. Three hours and four Python scripts later, you would realize that the problem was in a different component.

Over time, many standards and libraries have been developed to make logging easier, and React Native has plenty of logging functions. Our initial guide to logging in React Native is a good starting point. However, if you want to take things to the next level, this guide shows you how to use Sentry’s logging features to ensure your logs are useful and all the information you need is readily available.

Getting Logs into Sentry

This guide uses a simple React Native (Expo) app to show examples of Sentry’s various logging features. The app is a contact form with some basic validation on the fields. If you want to follow along and try for yourself, you can find the app in the demo repository.

Demo React Native app interface

If you have an existing React Native application, or plan to build one, this guide provides the steps required to take full advantage of logging with Sentry.

Set up

To start using Sentry features, we first need to install Sentry into our project. Start by creating a new project in Sentry and choosing React Native as the platform. Then, run the installation wizard to set up the necessary configurations in your local project:

Enable logging when prompted. When the configuration completes, you should see code like the following added to your main App.js class:

This initializes the Sentry SDK and enables logging with the Sentry logging library.

Sentry Logger API

Now that we’ve initialized Sentry and enabled logs, we can use the Sentry.logger namespace to send logs to our Sentry dashboard.

We can log messages with different log levels:

trace
debug
info
warn
error
fatal

We can also use the Sentry.logger.fmt function to add properties to the log message.

In the example app, add a new log call to the handleSubmit function:

After we click the Submit button, we will see an info level log on our Sentry dashboard.

We can manually add additional attributes to the logs. These don’t form part of the main log message but instead attach to the log and allow us to search or filter by them later.

To try this out, update the log that we added previously:

When we submit our form, we will see both the new filterID and extraMessage fields in the log payload.

Integrations

We have the Sentry Logger API working, but our app already has logging built with the default JavaScript console object. Luckily, we don’t have to rewrite all our logging because Sentry also provides a way to integrate with default JavaScript logging.

Update the Sentry.init call with the following code after the enableLogs: true line in App.js:

This causes all our existing logging to be sent to our Sentry. We can exclude certain log levels if we like. For example, if we want to reduce clutter on our dashboard, we could opt to send only error level logs.

However, as you’ll see later in this guide, we can also reduce clutter using the filtering in the dashboard itself, so it’s often better to send Sentry as much useful information as possible.

Let’s restart the app, fill in the form, and take a look at the logs that are sent.

Even with these integrated logs, Sentry links all the extra information available, such as the originating environment and browser type. All these data points can be used to filter, search, or group our logs.

Searching, filtering, and grouping

The Logs dashboard gives us access to all our logs in one place, as well as to tools for finding exactly what we need.

At the top of the dashboard, we can use the search bar to find specific log messages. We can search for text that appears in the log message itself or use Sentry’s query syntax to search by specific fields.

For example, we can get all the logs relating to submitting a form by typing sub in the search bar.

We can also search by log level. To see only warning logs, use the query severity:warn in the search bar.

We can also filter by the extra attributes that we added earlier. Type filterID:01 in the search bar.

When we have logs coming from multiple parts of our application, we can use custom attributes to quickly isolate logs from specific components or flows.

We can combine multiple filters together. For example, we could filter by both filterID and log level to see only warning logs from a specific part of our app.

Sentry also lets us group logs by different attributes. To do so, click the >> Advanced button, then open the Group By dropdown and select the type severity.

Our logs are now organized by their log level, making it easier to see how many logs we have at each severity. We can also group by environment, browser type, or any custom attribute we’ve added to our logs.

This becomes particularly useful when debugging an issue that affects specific users or environments. We can quickly group by browser or operating system to see if a problem is isolated to certain platforms.

Debugging a real application

To see the real value of Sentry logging, let’s look at a more complete example. We’ve built a cat voting app, where users can upvote or downvote cat pictures. The app has a React Native frontend that talks to an Express.js backend with a SQLite database. The frontend fetches cat images from an external API and stores them in the database.

If you want to explore the logging features for yourself, you can clone the app repository.

We’ve only set up Sentry on the frontend, as this guide is focused on React Native. We could, and should, create an Express.js Sentry project for our backend code as well.

The app structure

The app consists of:

A voting screen that displays cat images with upvote and downvote buttons
A winner screen that shows the most popular cat
A context provider that manages data fetching and state
An API service that handles all backend communication

This is what the Sentry setup looks like in the frontend/App.js file:

Tracking user actions

In frontend/src/screens/CatListScreen.js, we log when users vote on cats. We use both the logger API and breadcrumbs to create a trail of what the user does:

Debugging a backend issue

Let’s suppose some users report getting a 500 Internal Server Error (an API error) when they vote on specific cats. We turn to our Logs dashboard to investigate.

First, we check the dashboard for recent error logs. We filter by severity:error and see several Vote submission failed logs. We click on one of them to see the details.

The log shows us:

The cat the user tried to vote on (catId: "133")
The type of vote it was (voteType: "upvote")
The error message from the backend (errorMessage: "API Error: 500")
The timestamp of when the error happened

Because this is an error level event, Sentry also logs an Issue. We navigate to our Issues dashboard and click on the corresponding error event.

In the issue entry, we can scroll down and see the breadcrumb trail leading up to the error. The logs show the user loaded the cat list, clicked the upvote button, and then the API request failed with a 500 HTTP status code.

Now we know the problem is on the backend. We check the backend server logs around the same timestamp and find a database constraint error. The backend attempted to insert a vote, but the database rejected it due to a foreign key constraint violation (the cat ID doesn’t exist in the database).

Looking back at the Sentry logs, we search for when this cat was added. We filter by operation:fetchCats and see that the app fetched cats from the external API, but when it tried to save them to the database, one of the requests failed. The Sentry log shows:

The problem is clear: When the app fetched new cats, some were successfully added to the database while others failed due to duplicate IDs. Users could see cats that weren’t in the database, and when they tried to vote on those cats, the backend rejected the vote.

We can fix the issue by improving error handling in the cat fetching logic. When cats fail to save, we remove them from the UI so that users can’t vote on cats aren’t in the database:

Performance monitoring

In addition to errors, we can also track performance using Sentry’s spans feature. In frontend/src/context/CatsContext.js, we can monitor how long it takes to load cats:

Using spans provides better developer experience for performance tracking. You can view span data in the Performance tab of your Sentry dashboard, where you can easily identify slow operations and bottlenecks in your application.

The `beforeSendLog` function

We can use the beforeSendLog function to filter logs before they’re sent to Sentry. This is useful for controlling exactly which data reaches Sentry, helping us balance between having enough logs and not overwhelming our dashboard with noise.

For example, we can filter out debug-level logs in production, or remove sensitive information before sending logs to Sentry:

By returning null, we prevent the log from being sent to Sentry. This approach helps us maintain clean, relevant logs while protecting sensitive user information.

Going beyond Logs

Sentry logging turns logs from raw data into a useful and intuitive tool that could save us countless hours when diagnosing an issue. If you are still unclear about any of the steps required to set up Sentry’s logging features, you can turn to our documentation on setting up logs or setting up drains and forwarders.

As we touched on in this guide, logging goes hand-in-hand with Sentry’s other features, such as tracing and profiling.

With all these features set up, you can begin to take full advantage of the Sentry toolbox.

Not everything that breaks is an error: a Logs and Next.js story

Tue, 13 Jan 2026 00:00:00 GMT

Stack traces are great, but they only tell you what broke. They rarely tell you why. When an exception fires, you get a snapshot of the moment things went sideways, but the context leading up to that moment? Gone.

That's where logs come in. A well-placed log can be the difference between hours of head-scratching and a five-minute fix. Let me show you what I mean with a real bug I encountered recently.

Protecting an AI-powered Next.js endpoint from bots

I've been working on WebVitals, a Next.js application powered by AI. You enter a domain, and it runs a series of tool calls to fetch performance data, then uses an AI agent to parse the results and give you actionable suggestions for improving your web vitals.

On the frontend, I'm using the AI SDK's useChat hook to handle the conversation:

The /api/chat endpoint is a standard Next.js API route, which means anyone can hit it from anywhere. Since each request costs money (OpenAI isn't free), I needed some protection against bots and malicious actors trying to spike my bill.

Vercel has a neat solution for this: bot protection via their checkBotId function. It looks at the incoming request and determines if it's coming from a bot. Simple, effective, and no CAPTCHAs asking users to identify crosswalks.

A production bug that only affected Firefox and Safari

Everything worked perfectly in local development. Deployed to production, tested in Chrome. Still perfect. Then I opened Firefox.

"Access denied." The same request that worked in Chrome was getting blocked in Firefox. Safari had the same issue.

I checked Sentry. The error was showing up across multiple browsers, but only Firefox and Safari were affected. Chrome users were fine.

I tried fixing it. Multiple releases, multiple attempts. The error kept coming back. The stack trace wasn't helpful, it just showed me that the bot check was returning true for these browsers. But why would Firefox and Safari be flagged as bots when Chrome wasn't?

The stack trace couldn't answer that question.

Adding logs to capture the missing context

This is the kind of problem where you need more context than an error alone can provide. I needed to see what data the checkBotId function was working with when it made its decision.

So I added a log:

Nothing fancy. Just log the bot check result along with the user agent string that was passed to the function. Bot protection typically works by examining the user agent, so this seemed like the right data to capture.

The key here is that Sentry logs are high-cardinality. You can pass any attributes you want, and you'll be able to search and filter by them later. No need to decide upfront which attributes are "important". Just log what might be useful and let Sentry handle the rest.

Using Sentry Logs to identify the root cause

With logs in place, I headed over to Sentry's Logs view and searched for my "Bot ID check result" messages. I added the isBot attribute as a column so I could quickly scan the results. (In Sentry, boolean values show as 0 for false and 1 for true.)

I found a request that passed the bot check: isBot: 0. Looking at the details, the user agent was exactly what you'd expect: a standard Chrome user agent string.

Then I looked at a request that failed: isBot: 1. The user agent was... not what I expected.

Instead of the browser's user agent, I was seeing ai-sdk. The AI SDK was sending its own user agent string instead of the browser's.

This explained everything. When the AI SDK makes requests to the backend, it uses its own user agent. Vercel's bot protection sees ai-sdk and thinks, reasonably, that it's not a real browser. Bot detected. Access denied.

But why only Firefox and Safari? Because something in how those browsers (or my setup in those browsers) was causing the AI SDK's user agent to be used instead of the browser's. Chrome happened to pass through the correct user agent.

To confirm my hunch, I used Sentry's trace connection feature. Everything in Sentry is linked by trace, so I could navigate from the log entry back to the full trace view and see the broader context of the request.

Sure enough, the trace confirmed this was coming from Firefox. Mystery solved.

Fixing the issue once the data told the story

The solution was straightforward. In Vercel's firewall settings, I added a rule to bypass bot protection for requests where the user agent contains ai-sdk.

Saved the rule, published the changes, and tried again in Firefox.

It worked. No more access denied errors. It’s also being tracked in a Github issue on the AI SDK for those who are curious.

What this bug clarified about logging and debugging

This bug would have taken much longer to diagnose without logs. The error itself, "Access denied", told me nothing about why the request was being denied. The stack trace showed me where it happened, but not the data that caused it.

A few takeaways:

Logs provide context that stack traces can't. When you're debugging, you often need to know what the data looked like at a specific point in time. Errors capture the moment of failure; logs capture the journey.
High-cardinality attributes are powerful. Being able to search logs by any attribute: isBot, userAgent, makes it trivial to slice and dice your data. You don't have to predict which attributes will be useful ahead of time.
Trace connection ties everything together. Seeing a log in isolation is useful, but being able to jump from a log to the full trace (and vice versa) gives you the complete picture. In this case, it let me confirm that the AI SDK user agent was indeed coming from Firefox requests.

If you're already using Sentry for error tracking, adding logs is a natural next step. For new projects, you can use the Sentry.logger API directly. If you have existing logging with something like Pino, check out the logging integrations to pipe those logs into Sentry automatically.

Head on over to our Next.js Logs docs to learn more about how to send structured logs from your application to Sentry for debugging and observability. Or just check out our Logs quickstart guide and get up and running in no time.

Not everything that breaks throws an error. Sometimes you just need to see what was happening.

Meet Sentry’s 2025 Fall Interns

Mon, 12 Jan 2026 00:00:00 GMT

At Sentry, interns aren’t just observers, they’re teammates who ship meaningful work. This fall, our software engineering interns across our San Francisco and Toronto offices jumped right in, contributing to real projects that made a tangible impact. They built features, fixed tricky bugs, improved performance, and brought fresh perspectives that elevated our teams. Beyond sharpening their technical skills, they showed us exactly what the next generation of engineering talent can do. Here’s a look at their stories ✨.

Why Sentry?

Max

I really wanted to try working at a smaller company which Sentry provided. I thought that it was really cool being able to work in such a tight knit environment where you can see the decisions being made in a way that bigger companies don’t allow.

Jerry

I manage a course review platform (UWFlow.com) on the side, and one of the core maintainers told me to integrate Sentry because they used it at work. I begrudgingly did it, only to find it's actually not a bad tool. I later saw they were hiring and figured why not.

Cliff

When I previously interned at larger tech companies in the past, I felt that I had no real impact or ownership on any of the projects I worked on. The opportunity to receive a larger scope and ship impactful code that contributes to Sentry’s product stood out to me, which is why I chose to intern here.

What did you work on?

Max

I was on the Codecov team and I worked primarily on enabling reruns for tasks. This feature allowed admin users and support staff to much more easily help our customers best use the Codecov product.

Jerry

I was on the Session Replay team. I shipped live streaming replays, in addition to redesigning the Replay UI with playlists, and previous/next navigation.

Cliff

On the Session Replay team, I mainly worked on migrating Replay’s breadcrumb data from its own Snuba dataset to EAP (Events Analytics Platform), Sentry’s unified storage for observability data.

What was the internship like?

Max

I feel this internship provided a great opportunity to work on impactful projects where I could see the final business impact. A lot of times, I feel internships are defined completely by your manager/mentors, but here, I felt I was able to decide my own experience. I got to work on important issues as they came up, and helped the team in deciding what direction to take next. I feel like I was able to achieve a ton and learn a lot. Alongside the technical aspect, I really enjoyed doing all the internship events with the rest of the interns. We did an escape room and Chinatown food tour, and they were so fun.

Jerry

One of the most talent dense companies I’ve worked at in terms of engineering capability. My team was responsible for foundational projects that power Session Replay, and it was really interesting to be able to work alongside them and understand how they do things. In addition, there is a focus on work-life-balance that’s rare in tech. At the end of the day, it’s the people for me.

Cliff

I was able to work on challenging and high impact tasks during my internship here, which allowed me to solve really interesting problems and learn new concepts. My team was really friendly and gave me the opportunity to pursue projects that I was interested in (for example I was initially assigned a frontend project, but because of my interest in working on backend tasks, I was assigned a project that aligned with what I was interested in).

Looking ahead

If you're eager to explore our ongoing internship programs and gain valuable experience, we invite you to check out our careers page for more information. You'll find insights into our internship programs, application processes, and the benefits of joining our team.

Unity SDK 4.0.0: Console support, logs, user feedback and more

Thu, 08 Jan 2026 00:00:00 GMT

We just released the Sentry SDK for Unity 4.0.0 , our biggest update yet. This major release brings comprehensive gaming console support, structured logging, user feedback capabilities, and significant improvements to help you build better games across all platforms. Here's what's new:

Gaming console support

The Sentry SDK for Unity now provides native support for Xbox and PlayStation, bringing the full scope of Sentry's error tracking to gaming consoles. The SDK automatically syncs the scope to the native layer, so that when the game experiences a crash on consoles the captured issue has full stack traces with proper C# line numbers, Sentry provides custom contexts, tags, and breadcrumbs. This unified experience across all platforms makes it easier to triage and fix issues regardless of where they occur.

Structured logs

Structured logs are now production-ready in the Sentry SDK for Unity. This means that log output is directly connected to errors, crashes, and performance issues in your game.

The SDK automatically captures debug log output based on your configuration, creating structured log entries that you can browse and search on Sentry. When a player experiences a crash during scene loading or gets stuck in a loading screen, you'll have the complete log trail leading up to the problem, making it much easier to diagnose hard-to-reproduce issues.

User feedback

User Feedback support is now available in the Sentry SDK for Unity, enabling players to report issues or share general feedback about their gameplay experience. This helps bridge the gap between technical error data and player perspective, allowing you to see real player insights alongside stack traces and technical diagnostics.

The SDK includes a ready-to-use SentryUserFeedback prefab that you can drag and drop into your scenes or customize by creating your own prefab variant. Players can provide written messages with optional screenshots attached, helping you understand issues from their point of view. Of course, if you want to build your own custom feedback UI, you can submit User Feedback programmatically using the static API. Learn more about implementing User Feedback in the documentation.

Simplified configuration

The 4.0.0 release streamlines SDK configuration by consolidating Runtime and BuildTime configurations into a single OptionsConfiguration script. This simplification makes it easier to configure platform-specific options using preprocessor directives. This also allows you to opt-out of the auto-initialization behaviour, enabling you to programmatically call Init at any point during the game’s lifecycle, without sacrificing any features or support, i.e. native error coverage on mobile.

Check out the Migration Guide for details on updating your configuration.

Performance and reliability improvements

This release includes numerous fixes that improve stability across all platforms, most notably:

Fixed Android race conditions
that could cause crashes, especially in concurrent scenarios, by replacing the ThreadPool with a dedicated background worker thread that properly manages JNI lifecycle
Improved WebGL exception capture
through the logging integration for better stack trace support

Additional improvements include better debug symbol discovery, correct scene name reporting, improved Burst support, and thread-safe screenshot capture.

Enhanced context and debugging

The SDK now provides richer context automatically:

Screenshots on crashes - When targeting Windows with screenshot capture enabled, the SDK will now capture and attach screenshots to native crashes
Memory reporting - Allocated memory is now reported with every event and transaction
Low memory breadcrumbs - Automatic breadcrumbs for Application.lowMemory events
Lifecycle breadcrumbs - Automatic tracking when the game loses and regains focus
Session improvements - Exceptions are correctly marked as unhandled rather than crashed, and sessions now persist from game start to end

For third-party plugin users, the SDK automatically marks stack frames from popular libraries like Cysharp and DOTween as non-in-app, significantly improving stack trace readability and issue grouping.

Breaking changes

This major release drops support for Unity 2020, which reached End of Life in 2023. The minimum supported version is now Unity 2021. Additionally, if you're running your game or your server on Ubuntu 20.04, you should update to Ubuntu 22.04 before upgrading to this SDK version, as sentry-native is now built against the newer Ubuntu version. For a complete list of breaking changes and migration guidance, see the full changelog.

Platform support and getting started

The Sentry Unity SDK supports Windows, Linux, macOS, iOS, Android, Xbox, and PlayStation.

To get started:

Download from GitHub Releases
Read the Unity SDK documentation
Explore the updated sample scenes

Have questions or feedback? Join the conversation in Discussions! If you're new to Sentry, you can explore our interactive Sentry sandbox or sign up for free.

Trace-connected structured logging with LogTape and Sentry

Wed, 07 Jan 2026 00:00:00 GMT

As our applications grow from simple side projects into complex distributed systems with many users, the “old way” of console.log debugging isn’t going to hold up. To build truly observable systems, we have to transition from simple text logs to structured, queryable, trace-connected events.

Would you rather watch this blog in a video format? Check out Production Logging for JS with LogTape + Sentry on YouTube.

TL;DR: The Logging Strategy Shift

Many of us treat logs like a breadcrumb trail, verifying that each line executes, and logging the outputs for debugging. In production, that breadcrumb trail turns into a mountain of noise. We need to move from logging the process to logging the milestone.

Clear the noise: Move away from "thin" logs that create noise, are difficult to query and correlate.
Embrace high cardinality: Pack your logs with "fat" context that builds up over a task. Include User IDs, Order IDs, Cart information, and more so you can query for the data you need for any given event.
Connect the dots: Use Sentry to keep logs trace-connected; linking every log to the specific request that triggered it.

The Log Dump: Why `console.log` fails in production

Once logs stop being centralized and chronological, console.log breaks down. In a production environment with multiple users and services, your logs quickly turn into an interleaved stream of events with no clear way to reconstruct what happened for any single request.

Without a shared trace to connect related logs and useful, filterable data, these logs become essentially useless in production.

Implementing production-grade logging with LogTape and Sentry

Sentry provides trace-connected logging. With traces, you can see the full context of a request, including all of the logs associated with it. This will give us an easy way to query for the traces and logs associated with an issue or request.

Additionally, Sentry provides a powerful query engine that we can use to search our logs based on attributes and structured data. From there, we can create alerts and dashboards based on our results.

LogTape is a lightweight logging library for all JavaScript runtimes. Logging libraries like LogTape provide a way for us to instrument our code with automatic, rich structured logging and send those logs to Sentry using a "log sink".

Structured logging is a format where, instead of simple strings, we treat a log as a structured object with defined properties.

That allows us to write powerful queries and filters to find and surface the data we need from our logs for debugging in production.

Example from the LogTape Structured Logging manual

Quick start: Next.js setup

We'll be using the Next.js framework for this example, but the concepts can be applied to any JavaScript framework.

You can follow the Quick Start guide for your framework of choice to initialize Sentry in your project. For Next.js, we'll use the @sentry/wizard to initialize Sentry in the project.

After the wizard completes, you should see that a few files were created in your project, which will automatically instrument your project with error monitoring and begin capturing traces and logs.

instrumentation-client.ts — Runs in the browser
sentry.server.config.ts — Runs in Node.js
sentry.edge.config.ts — Runs in edge runtimes

Your instrumentation-client.ts file should look similar to this:

You'll also have a new /sentry-example-page route that will help you test that Sentry is working.

If you start your development server, navigate to the example page, and click the "Throw error" button, you'll see the issue captured in Sentry, and the associated trace.

This trace links everything related to a request, including issues, session replays, and logs.

Configuring LogTape with Sentry

We are already configured to receive logs on Sentry, but we need to define how we want to send those logs.

To receive structured logs with LogTape, we'll take advantage of the "log sink". Rather than (or in addition to) sending the logs to the console, we can send our trace-connected logs directly to Sentry.

First, install the LogTape and LogTape Sentry packages:

Client-side configuration

In your instrumentation-client.ts file that we looked at above, we'll add the LogTape configuration.

We'll break this down after we configure the rest, but in short, we're configuring LogTape so that when we use the logger object, it will send the logs to the console and Sentry.

We are also setting a category for the logs, which will be used to group logs together in Sentry by domain.

Server-side configuration

LogTape has a special feature called contexts that allows us to pass data down the call stack. Meaning, we can easily append contextual data to the log stack at any point, to be included in any logs submitted.

On the backend, we can take advantage of implicit contexts, which will allow us to append data to all logs in the stack. By adding the configuration below, we can utilize the withContext method to automatically insert data at the current scope, and all subroutines will inherit that information automatically.

In your sentry.server.config.ts file, we'll add the LogTape configuration for the server.

We'll use implicit context inheritance to build up and collect data throughout our app in a partially automated way. Then when we do finally log a message, it will contain debugging information from the whole stack until that point.

Using LogTape in your Next.js app with Sentry

With Sentry and LogTape configured, we can start using the logger object to log messages.

We use getLogger to fetch the root logger for the given category, which we set in the instrumentation-client.ts, and sentry.server.config.ts files for the frontend and backend, respectively.

You'll notice here we have also set an additional category api, which will ensure all logs on this scoped child logger will be tagged with category: nextapp-demo.api , which we can query later.

You can continue to scope this further as needed with nesting.

In Explore > Logs, this query is searching for logs where category "contains" nextapp-demo.api, meaning this query shows all API logs, including those under the .api.posts, nested category.

Querying LogTape in Sentry

After collecting a few logs from your frontend and backend in your app, navigate to the Log Explorer in Sentry.

We saw that we can set categories, like api, or even an array of nested categories. Combined with the structured data sent in our logs, we can build queries based on any available attributes.

Each log created with our logger will contain the inherited attributes, all options we can query on.

From queries to alerts and dashboards

Once your logs are structured and queryable, you can turn those same queries into alerts and dashboards in Sentry.

Now you can configure alerts, for example, where there is a higher-than-average number of warn logs in a given component or service, and you can configure that specific alert to notify a specific team or developer.

Strategy: What (and when) to log

Before we instrument every function, we need a plan. High-volume production apps can generate millions of logs, leading to "noise" that's potentially difficult to sift through, and eats through storage limits.

Choosing the right level

We use log levels as a top-level filter to reduce the noise. In production, we typically set our Sentry sink to info or warn, while keeping the console sink at debug for local work.

Debug: High-volume data (e.g., "Rendering PostItem ID: 123").
Info: Major lifecycle events (e.g., "User login," "Payment processed").
Warn: Recoverable issues (e.g., "API timeout, retrying").
Error: Critical failures that require immediate attention.

When to log: The event-driven approach

To keep our signal-to-noise ratio healthy, we don't log every line of code. Instead, we log transitions:

The "Happy Path" Boundaries: Log when a major process starts and ends (e.g., checkout_started -> checkout_completed).
External Dependencies: Calling an external dependency has a high potential for failure. You may want to add a log prior to calling any external dependencies, specifically with data from the request payload that may be useful in debugging in the event of failures in the future.
Recoverable Errors (Warn): Use the warn level for things that didn't break the app but aren't "normal," like a cache miss that required a heavy database rebuild. These types of queries will be especially useful for monitoring performance or creating alerts.

Less logs, more cardinality

A common trap is thinking you shouldn't “stuff” your logs with data because it might bloat log sizes or increase costs. In reality, a thousand logs won't help you if they don’t contain the specific data needed to reproduce a bug.

Cardinality refers to the uniqueness of the data within your logs. High-cardinality data includes things like userId, sessionId, orderId, and requestId. While older self-managed logging stacks struggled with high-cardinality data (it made queries slow), modern tools like Sentry thrive on it.

The shift: From "chatty" to "contextual"

We want to move away from logging every individual line of execution and instead move toward logging milestones with accumulated context.

Consider a cart checkout flow. In the "old way," you might have several distinct log lines:

The "Chatty" trace (Distributed but thin)

You have multiple “thin” logs, each trace connected, but the data within can’t easily be queried together. To see the orderId and the totalAmount, you have to click through the trace, find the specific "Payment processed" log, and hope the developer included the ID there.

The "High-Cardinality" event (Rich and actionable)

Instead of relying on the trace to "stitch together" a story from thin logs, we log milestones with accumulated context.

Even with tracing, high-cardinality logs are superior for two reasons:

1. Global searchability

Tracing helps you debug one specific request. High-cardinality logs help you debug the entire system. You can go to the Sentry Log Explorer and ask:

"Show me every 'Purchase Completed' event in the last 24 hours where discountCode was 'SAVE20' and latencyMs was > 2000."

You can't do that if the discount code was buried in a different log line three steps back in the trace.

2. Reduced mental overhead

When you open an issue in Sentry, seeing one "fat" log entry with all relevant IDs and state is significantly faster than hunting through a list of 20 "thin" logs to piece together what the user was doing.

By focusing on "Event-Driven" logs with high cardinality, you turn your logs from a simple diagnostic trail into a powerful internal analytics engine.

Real-world usage of LogTape in React

Unlike the backend, the browser lacks the AsyncLocalStorage API for implicit context. To avoid manually attaching user data to every log, we can use React Context to automate inheritance.

Let’s take a look at how to structure our project with React Contexts to automatically instrument our logs with useful data contextually.

Create a logger context.

In *lib/logger-context.tsx*, or wherever you define your context providers, create this file.

Then, wrap your app with the provider. This is usually done with layouts.

Now every component gets a logger with user context automatically:

Every log automatically includes { user: { id, email, name } } without manual configuration!

The .LOG (Recap)

Structured data > Strings: Use objects to make logs searchable.
Nested organization: Use nesting categories to easily query up and down a stack.
Sink strategy: Utilize filtered sinks to send only the data you want to send, where you want to send it.
Context is King: Use AsyncLocalStorage (Server) and React Context (Client) to stop repeating yourself in log statements, and ensure the data you need is included.
Traceability: Easily discover all logs in a single request via traces.
High cardinality: Use high cardinality logs at the end of events to create rich metrics from queries.
Monitoring: Use alerts and custom dashboards to keep an eye on important metrics.

You can read more about LogTape and structured logging in the LogTape manual. Get more acquainted with Sentry’s logs with our interactive demos.

Another year, another $750,000 to Open Source maintainers

Tue, 06 Jan 2026 00:00:00 GMT

Bored yet? 2025 was the fifth year in a row (2024, 2023, 2022, 2021) that Sentry gave a pretty hefty chunk of change to the maintainers of the Open Source software that we rely on and love.

This is our first report since we launched the Open Source Pledge, which brings together companies that share our respect for the independent maintainers in the community. Pledge members have collectively paid $4.5M to Open Source maintainers and foundations since launch. No more excuses! Companies paying maintainers is real. You should join the party. :-)

As always, you can see the details of our primary distribution ($375k) on thanks.dev (TD). They’re the easy button. You have no excuse. Go sign up your company for thanks.dev and pay the maintainers of the projects you rely on. If you meet the Pledge minimum ($2000/dev/yr) and blog about it, we’ll add your company to the list. The more who join, the more who will join, and the stronger and more resilient the Open Source ecosystem will be.

We also continue to work with Open Source Collective / Ecosyste.ms Funds ($75k) as well as GitHub Sponsors ($50k). Like thanks.dev, Ecosyste.ms Funds makes it easy to support a number of projects at once, but they don’t look at our dependencies to see what projects we’re actually using in a given ecosystem. Their overall data is top-notch, though, and so we give 10% through them to ensure broad support for the ecosystems we rely on. Sadly, Microsoft mothballed Sponsors this past year. There were no Sponsor-related announcements at Universe, and they’ve stopped new feature development on the product with the shift to AI.

Speaking of shifts to AI, Sentry is of course selling shovels as fast as we can, while also shoveling, ourselves. NumFOCUS manages a lot of the Python projects at the heart of the modern AI stack that most companies rely on, including Sentry, so this year we’ve added them to the list of foundations we support. Thanks.dev also handles all these logistics for me, which is a big help. Really, you have no excuse.

Recipient	Amount ($)
Django Software Foundation	30,000
Outreachy	25,000
Open Source Initiative	20,000
Python Software Foundation	16,750
Geomys	15,000
OpenJS Foundation	15,000
PostgreSQL	15,000
rrweb	15,000
Rust Software Foundation	15,000
PHP Foundation	12,000
Ruby Central	10,000
.NET Foundation	10,000
NumFOCUS	10,000
Apache Software Foundation	10,000
TOTAL	218,750
% of 750k	29

As ever, a hearty thank you to all you Open Source maintainers out there. Keep up the great work!

Building a Code Review system that uses prod data to predict bugs

Thu, 18 Dec 2025 00:00:00 GMT

This post takes a closer look at how Sentry’s AI Code Review actually works.

As part of Seer, Sentry’s AI debugger, it uses Sentry context to accurately predict bugs. It runs automatically or on-demand, pointing out issues and suggesting fixes before you ship.

We know AI tools can be noisy, so this system focuses on finding real bugs in your actual changes—not spamming you with false positives and unhelpful style tips. By combining AI with your app’s Sentry data—how it runs and where it’s broken before—it helps you avoid shipping new bugs in the future.

High-level architecture

The code review system detects bugs using both code analysis and Sentry data to deliver suggestions to your PR.

Here’s an overview of AI Code Review’s architecture:

Bug prediction pipeline

To predict bugs with as much precision as possible, we employ a multi-step pipeline based on hypothesis and verification:

Filtering - In this step we gather PR information and filter down PR files to the most error-prone. Especially important for large PRs;
Predicting - The exciting part. Here we run multiple agents that draft bug hypothesis and verify them;
Packaging & Shipping - Aggregate suggestions, filter and parse them into comments, then send them to your PR;

Later on, we will look at some traces from the getsentry/sentry repo that shows the pipeline in action.

Filtering

For PRs with only a few changes, we add all files into the agent’s context. But to prevent the agent from being overwhelmed by large changes, if more than five files will be changed, we narrow it down to most error-prone files.

This is done using an LLM that is instructed to drop testing files and doc changes, as well as files that superficially look less error-prone. That said, test files are searched during both draft and verify agent runs (in the step below).

Predicting

Because context is king, all agents have access to different tools that provide them with rich context to understand the code being analyzed.

Our predictions are ultimately based on:

Actual code change
PR description
Commit messages
Sentry historical data for this repository (see How Sentry context is used for details)
Code from the repository (via code-search tools)
Web information (via web-search tools)
“Memories” gathered for the repository across PRs. These are specific details about your repository that the system learns overtime with every PR it analyzes. We keep a list of up-to-date, relevant tidbits of information about the repository that is updated with every new PR analyzed. These are things like “tests for this repository use pytest assertions” or “The root_task in tasks.py has a hard time limit of 15 minutes (900 seconds).”

The agent workflow generates hypotheses and attempts to verify each one.

Draft hypotheses: A drafting agent creates a report containing an initial analysis of potential bugs. This report is split into at most 3 bug hypotheses.
Verify hypothesis: Concurrently, each hypothesis is analyzed by a dedicated agent. Each verify agent has access to tools to fetch sentry issues and event details. See How Sentry context is used for details.
Gather results: A final agent gathers all the results and aggregates them into a list of verified bug predictions.

By focusing the verifying agents into a single hypothesis they can deep dive and more correctly assert if that is a valid bug or not.

That’s how we keep the signal-to-noise ratio high for bug predictions.

Example

Let’s look at another example trace for this PR in getsentry/sentry. Specifically for commit 596e046c05cb6ec43ebf924dbc40fd1e3f40db26.

File filtering

Draft Hypothesis

Now I have a comprehensive understanding of the code changes. Let me analyze the potential issues:

Analysis

This code change is refactoring analytics.record() calls from using string-based event names to using class-based event objects. The repository context mentions that analytics.record() calls should be wrapped in try/except blocks to prevent failures from propagating, as analytics recording is considered non-critical.

Looking at the changes:

Most changes lack error handling: In files like
src/sentry/integrations/slack/webhooks/event.py, src/sentry/integrations/discord/webhooks/message_component.py, src/sentry/integrations/discord/webhooks/base.py, and src/sentry/sentry_apps/installations.py, the refactoring changes the analytics.record() calls but doesn't add any try/except error handling.
Only one file adds proper error handling: In src/sentry/rules/actions/integrations/base.py, the code properly wraps the new analytics.record() call in a try/except block with sentry_sdk.capture_exception(e).
Missing imports: The new event classes are being imported, but I need to verify if these could fail during instantiation.

Potential Bugs

Based on my analysis, here are the potential bugs I've identified:

1. Missing error handling for analytics.record() calls

Location:

Description: The repository context specifically states that analytics.record() calls should be wrapped in try/except blocks to prevent failures from propagating and causing user-facing errors. However, most of the refactored analytics.record() calls in this change do not include this error handling, while they're changing from string-based to class-based event recording.

The new class-based approach could potentially introduce new failure modes during event class instantiation that weren't present with the old string-based approach. For example, if the event class constructors perform validation on the input parameters or if there are issues with the class registration, these could raise exceptions that would now propagate up the call stack and potentially crash the request.

Important things to investigate further:

Whether the new event classes perform any validation during instantiation that could raise exceptions
Whether the old string-based analytics.record() calls had any implicit error handling that's now missing
Whether these analytics calls are in critical request paths where an exception would cause user-facing errors

2. Potential field mismatch in refactored analytics calls

Location: src/sentry/integrations/slack/webhooks/event.py:205~211

Description: The original analytics call included a user_id field implicitly, but the new IntegrationSlackChartUnfurl class shows user_id: int | None = None as an optional field. The refactored code doesn't pass user_id, so it will default to None. I need to check if this was intentional or if user_id should be passed from the request context.

Important things to investigate further:

Whether the original call was supposed to include a user_id parameter
Whether the missing user_id field affects analytics data collection in a meaningful way

Based on the repository context emphasizing that analytics.record() calls should be wrapped in try/except blocks, and the fact that most of the changes in this PR don't include this protection, I consider the missing error handling to be the primary potential bug that could cause unexpected crashes in production.

You’ll notice that in what becomes hypothesis 1 the agent says “The repository context specifically states that analytics.record() calls should be wrapped in try/except blocks to prevent failures from propagating and causing user-facing errors”. This comes from the “memories” that we generated for the repository.

Memory context

The exact piece of memory passed to the agent: When calling analytics.record() in API endpoints or other critical request paths, wrap the call in a try...except Exception as e: sentry_sdk.capture_exception(e). This ensures that failures in analytics event recording (e.g., due to invalid event data or internal analytics system issues) do not propagate and cause user-facing errors or block the main request flow. Analytics recording is considered non-critical for the primary user experience.

Analysis of Hypothesis 1

The initial analysis of the bug before evaluating it against the bug guidelines: <initial_followup> Based on my thorough investigation of the codebase, I now have a clear understanding of the hypothesis and the evidence. Let me analyze this systematically:

Evidence Analysis

1. Repository Context Verification

The repository context correctly states that analytics.record() calls should be wrapped in try/except blocks. However, my investigation shows this guidance is inconsistently followed across the codebase.

2. Existing Error Handling Patterns

Looking at actual implementations:

Examples WITH proper error handling:

src/sentry/middleware/devtoolbar.py: Wraps analytics.record() in try/except with sentry_sdk.capture_exception(e)
src/sentry/rules/actions/integrations/base.py: The code change itself shows proper error handling for analytics.record() calls
src/sentry/api/endpoints/organization_events_stats.py: Contains analytics.record() wrapped in try/except with sentry_sdk.capture_exception(e) specifically for agent monitoring queries

Examples WITHOUT error handling: From my search results, I found hundreds of analytics.record() calls throughout the codebase that lack try/except protection, suggesting this is a widespread pattern, not an isolated issue.

3. Sentry Issues Evidence

The Sentry issues I examined show:

Issue 6871320642: A KeyError occurring during analytics event serialization, specifically in SentryAppSchemaValidationError.serialize(). This demonstrates that analytics.record() can indeed fail with runtime exceptions.
Issue 6847278399: A ValueError occurring when analytics event validation fails for missing required attributes in TrialUsageEndNotification. This shows another way analytics events can throw exceptions.

Both of these issues show that the analytics system can fail in various ways, supporting the hypothesis that analytics.record() calls can raise exceptions.

4. New Class-Based Events Risk Assessment

Looking at the code change, the refactoring moves from string-based events to class-based events:

Old approach:

New approach:

The new approach introduces event class instantiation, which could potentially fail during:

Class constructor validation
Field validation
Dataclass transformation (as evidenced by the Sentry issues)

5. Critical Request Path Analysis

The files being modified include:

These are critical request paths where an unhandled exception would cause user-facing errors.

Bottom-Up Assessment

Evidence supporting the hypothesis:

✅ Repository context explicitly states analytics.record() should be wrapped in try/catch
✅ Real Sentry issues show analytics.record() can fail with various exceptions
✅ Only one of the modified files (src/sentry/rules/actions/integrations/base.py) includes proper error handling
✅ The other files lack error handling despite being in critical request paths
✅ The new class-based approach potentially introduces new failure modes
✅ Similar patterns in other parts of the codebase already include try/catch for analytics.record()

What I couldn't verify:

The exact likelihood of the new event classes failing during instantiation
Whether the specific event classes used in the code change have known validation issues

Conclusion

The hypothesis is VALID as a real bug. The evidence strongly supports that:

The repository explicitly requires analytics.record() calls to be wrapped in try/except blocks
Real production issues demonstrate that analytics.record() can and does fail with various exceptions
The code change violates this guideline in multiple critical request paths
The new class-based approach could introduce additional failure modes compared to the old string-based approach

This is a genuine bug that could cause unexpected crashes in production when analytics events fail to record. The fact that only one of the modified files (src/sentry/rules/actions/integrations/base.py) includes proper error handling while the others don't makes this a clear violation of the established pattern and could lead to user-facing errors in critical integration workflows. </initial_followup>

The revised followup findings after applying the bug guidelines: <revised_followup> Looking at my analysis against the specific filtering guidelines for missing error handling:

Filtering Against Missing Error Handling Guidelines

1. Evidence that the block could raise an error: ✅ STRONG EVIDENCE

Two concrete Sentry issues (6871320642, 6847278399) demonstrate analytics.record() failures with KeyError and ValueError
Repository context explicitly states analytics calls should be wrapped in try/except
Multiple existing examples in the codebase already wrap analytics.record() in try/except

2. Graceful handling is the right thing to do: ✅ CONFIRMED

Repository context explicitly states analytics recording is "non-critical for the primary user experience"
Failures should not propagate to cause user-facing errors
Analytics is clearly intended to be non-blocking

3. Code execution context - end-user vs backend: ✅ USER-FACING CODE

These are all user-facing integration endpoints where unhandled exceptions would:

Cause webhook failures visible to users
Break integration functionality
Return error responses to external services (Slack, Discord)

4. Tracing execution to bottom of stack: ✅ CONFIRMED

Webhook failures would propagate to external services
Installation failures would be visible to users in the UI
No higher-level error handling wraps these analytics calls

Revised Analysis

The hypothesis is VALID as a real bug. This meets all criteria for missing error handling:

Strong evidence of potential failures: Real production Sentry issues demonstrate analytics.record() can fail
User-facing code paths: These are integration endpoints where failures directly impact users
Repository guidelines violated: Explicit guidance to wrap analytics.record() calls is not followed
Graceful degradation required: Analytics failures should not break core functionality

The bug could cause:

Webhook integration failures for Slack/Discord users
Sentry App installation failures
Broken integration workflows

This is a genuine missing error handling bug in critical user-facing code paths. </revised_followup>

As part of evidence gathered by the agent to validate hypothesis 1 you’ll notice that it points to past Sentry issues in the code base. They follow from similar code patterns as the one the agent was analyzing.

Analysis of Hypothesis 2

The initial analysis of the bug before evaluating it against the bug guidelines: <initial_followup> Based on my analysis, I can now provide a definitive assessment of the hypothesis. Let me examine the evidence:

Analysis of the Hypothesis

The hypothesis states that "The refactored analytics call for IntegrationSlackChartUnfurl does not pass a user_id, causing it to default to None. The original string-based call may have implicitly included this field, so its omission in the new class-based call could result in a loss of important analytics data."

Evidence from the Code

Looking at the exact code change in src/sentry/integrations/slack/webhooks/event.py:

Original code:

New code:

Key findings:

The original call did NOT include user_id: The original analytics.record() call only passed organization_id and unfurls_count=0. There was no user_id parameter in the original call.
The IntegrationSlackChartUnfurl class definition (from src/sentry/integrations/slack/analytics.py):

Context where user_id is available: In the on_link_shared method where this analytics call occurs, there is access to slack_request.user_id and request.user. Throughout the file, slack_request.user_id is used extensively for logging and other purposes.
Different usage in another file: In src/sentry/integrations/slack/unfurl/discover.py, the same IntegrationSlackChartUnfurl class IS used with a user_id:

Conclusion

The hypothesis is INVALID.

Here's why:

No implicit user_id in original call: The fundamental assumption of the hypothesis—that the original string-based call "may have implicitly included" a user_id field—is factually incorrect. The original call explicitly did NOT include any user_id parameter.
Consistent behavior: Both the old and new implementations omit user_id, so there's no change in behavior. The new call defaulting user_id to None is the same outcome as the original call not including user_id at all.
Not a data loss: Since the original call never captured user_id, there's no "loss of important analytics data" as the hypothesis suggests. The analytics were already missing this information.

While it's true that the refactored code could potentially include the user_id (since slack_request.user_id is available in the context), the absence of this field is not a bug introduced by the refactoring—it's a preservation of the existing behavior.

This is not a bug that would cause server crashes, major logical issues, or performance problems. At most, it could be considered a missed opportunity for enhanced analytics, but that would be a separate enhancement request, not a bug introduced by this refactoring. </initial_followup>

The revised followup findings after applying the bug guidelines: <revised_followup> Since I concluded in my followup analysis that the predicted bug is not valid, I'm skipping this filtering step as instructed.

The hypothesis was invalid because the original analytics call never included a user_id parameter, so the refactored call maintaining this same behavior (with user_id defaulting to None) is not a bug - it's preserving the existing functionality without any data loss. </revised_followup>

In the end Hypothesis 1 is marked as a potential bug and showed to the user here. It includes reference to one of the Sentry issues used to validate the hypothesis.

How Sentry context is used

The verify agent is instructed to adopt a “click-into” flow for analyzing issues. First, it searches for a large set of issues, receiving a short summary of each. Next, if the agent believes a particular issue is relevant to the code change, it fetches details about that issue. This flow allows the agent to decide on its own whether it needs runtime knowledge to analyze the bug, and keeps its context focused.Here are the search tools the agent may call:

Fetch past Sentry Issues by keywords. This tool is akin to giving the agent the ability to search the Issue Feed in the Sentry UI.
Fetch past Sentry Issues by error type. This tool is useful when the agent can guess the bug’s specific error type (e.g., KeyError) and wants to see if similar bugs have occurred in the past. For example, is the code attempting to access data which—upon inspection of the object in production—is missing keys/attributes?
Fetch past Sentry Issues by file name and function name. This tool returns issues with an error whose stack trace overlapped with a specific function. The agent is instructed to use this tool to inspect variable values in production, or to determine if certain functions are known to be part of error-prone paths in the code.

Each of these searches returns, for each matching issue, the issue ID, title, message, code location, and (if it exists) Seer’s summary of the issue, which is based on the error event details and breadcrumbs. With this information, the agent can determine if any of the returned issues are relevant enough to warrant a closer look. If so, it can call a tool to fetch the event details, which includes the stack trace and variable values for that issue. This tool also returns (if it exists) Seer’s root cause analysis of the issue. At this point, the agent may incorporate this production/runtime context into its analysis. If it does, the bug prediction comment contains links to relevant Sentry issues.

Maintaining quality predictions

After we gather all suggestions, they go through an extra filtering stage to ensure you only receive suggestions that are relevant to you. We filter on a number of criteria, but the main ones are:

Confidence and severity The agents that generate suggestions also provide an estimate of their confidence that the issue should be addressed and an assessment of its severity. The scale is 0.000 to 1.000, with 1.000 being a guaranteed production crash. Suggestions with low confidence or low severity are discarded.
Similarity with past suggestions
In suggestion similarity we look at past suggestions for a repository and how that team reacted to them (by tracking 👍/👎 reactions in the comments). We use embeddings and cosine similarity (aka vector search) to filter out suggestions that are too similar to downvoted suggestions sent in the past. This empowers teams to select what kinds of suggestions they want to receive from the reviews.

Agent evaluation

To validate our system’s performance, we periodically run a set of known bugged and safe PRs through our bug predictor. We do this to evaluate performance and cost, prompt changes, model changes, new context and architectural changes. Each run gives us numbers for precision, recall, and accuracy that we've consistently improved over time. This also provides early signal if we're about to introduce regressions to the system. That said, while these metrics provide a useful directional signal, we recognize their limitations and avoid over-indexing on them. This controlled, consistent evaluation has been key to maintaining confidence in the system as it evolves. And while building this evaluation pipeline was costly upfront, it’s more than paid off in the reliability and trust we now have in the product.

Dataset collection

All datasets are stored in Langfuse. Each dataset item specifies an existing PR and what the expected bug(s) are (can also be no bug). Currently we have several datasets we run our evals against:

bug-prediction - the giant set of baseline tests. This was manually curated by the team when we initially started building the AI agent. Today it contains around 70 items. Typically we use this to report our scores (precision, recall, accuracy)
bug-prediction-performance-issues - a dataset dedicated to performance issues, with the introduction of improving the agent to predict performance bugs we’ve introduced a set of PRs with performance issues.

Context mocking

One of the core features of the bug prediction agent is the ability to analyze Sentry context therefore in the agent evaluations it is important to evaluate the qualities of it.

The simplest approach is to directly fetch Sentry context from the live Sentry API similar to how the production system would do it, however doing so would introduce three major problems in the context of evals:

The results from Sentry API between multiple runs would be inconsistent because new Sentry contexts (eg a new Sentry Issue was created) might be introduced or existing Sentry contexts might be updated between the first and second run.
Depending on the dataset item (ie the PR used for eval) and when the evaluations was ran there might be a chance that a leaking problem might be introduced, meaning information that should not have been available to this test was made available. An example of this would be if the PR being tested was able to fetch a Sentry Issue that was created as a result of that said PR. In production this would not be an issue because naturally the changes in the PR has not made it to the system yet when the agent is ran, however in our evaluation dataset the PRs we selected might have been merged already.
Querying from the live API is not very performant, the evaluations we currently have is aimed at understanding the quality of the predictions not so much the performance aspect of it (performance testing is separate from evaluations).

To solve for each of the problems above we have opted to use a “context mocking” solution where Sentry context are snapshotted, cached, and fetched locally during evaluation runs.

To snapshot existing DB of Sentry contexts we run a tool when a new dataset of PRs are created. This tool fetches all Sentry contexts up to the timestamp of the PRs ensuring nothing is fetched from timestamps after the creation of those PRs.
All the data is sanitized and indexed into a small SQLite file that is uploaded to our cloud storage to be downloaded at the start of each evaluation run.
When running the agent in evaluation mode, instead of fetching from live Sentry API, we mock those tool calls to these set of mocked tools that would fetch Sentry context directly from the local SQLite DB.

Where AI Code Review is going next

Like any software, we’re constantly working to make AI Code Review better and more useful. We continue to improve it through evaluations, investigating new context to add, changing prompts, and a lot more. We’re exploring more context sources to find the most impactful context, and working on making the predictions more actionable so you can fix issues as easily as the review brings them up.

Try it out and let us know how it’s going.

Cocoa SDK 9.0.0 has landed

Tue, 16 Dec 2025 00:00:00 GMT

We just released Cocoa SDK 9.0.0, here's what's new, and what's changed.

It's been a while since the last major version. The last major release, 8.0.0, shipped on January 16, 2023. After 57 minor and 47 bug fix releases, it’s finally time for a new major version to land: 9.0.0.

Why now

Our minimum supported OS versions had drifted low enough that some users started seeing more Xcode warnings than they’d like. A bit too much "Compatibility is King". So it’s really time to do a major update and bump the minimum supported OS versions.

What kind of release this is

Version 9 is a maintenance major. This means:

We bumped minimum OS versions
We enabled a few features by default
We cleaned up a bunch of small API issues

It should be easy for you to upgrade. Famous last words.

Changes you’ll want to know about

Most of the changes in version 9 fall into three buckets: platform requirements, defaults we’ve turned on for you, and cleanup we’ve been meaning to do for a while. Here are the essentials:

Updated minimum supported OS versions

We bumped the minimum supported OS versions:
- iOS: from 11.0 to 15.0
- tvOS: from 11.0 to 15.0
- macOS: from 10.13 to 10.14
- watchOS: from 4.0 to 8.0
- visionOS: 1.0 (unchanged)

Tooling and defaults

We now use Xcode 16 for building the precompiled XCFramework, and we set the swift-tools-version to 6.0.
Structured logs are no longer experimental.
HTTP client errors now mark sessions as errored. This provides better visibility into failed network requests in the release health data.
App Hang Tracking V2 is now the default on iOS, tvOS, and macCatalyst.
Tracing: We enabled pre-warmed app start tracing by default, and the app start duration now finishes when the first frame is drawn instead of when the OS posts the UIWindowDidBecomeVisibleNotification.
Profiling: We removed the deprecated transaction-based profiling. You now have to use UIProfiling.

Package managers and SDKs

Compiling from source via SPM works again, but we don’t officially support it yet.
Our Carthage support has been broken for a while, and at this point it’s clear it’s not something most teams are relying on. So we’re officially dropping it.
We added a new SDK, SentryDistribution, that keeps internal builds up to date; it’s the Sentry version of Emerge Tools’ ETDistribution 🚀.

The complete list of all changes is even longer. If you want to see everything, check out the migration guide or the 9.0.0 changelog to see it.

Upgrading to version 9

Simply update your package manager to use the latest version of version 9 and then check the migration guide to see if you need to change anything. That's all there is to it for most setups.

What about version 8?

We have stopped feature development for version 8 and will only ship critical bug fixes. You still can use version 8 and aren’t forced to upgrade to version 9, but we still recommend updating to the latest major version if possible.

If you're ready to upgrade

If you’re able to, give version 9 a try. We’re excited to see what you build with it. And if something breaks, or even just feels off, open an issue. We’ll help you sort it out.

A better way to monitor your AI agents in .NET apps

Thu, 11 Dec 2025 00:00:00 GMT

We launched agent monitoring earlier this year, allowing our users to instrument LLM usage and tool calls in their applications. However, we only had Agent Monitoring support for Python and JavaScript. We’ve been working on creating an Agent Monitoring SDK for .NET — specifically for Microsoft.Extensions.AI.Abstractions.

Introducing `Sentry.Extensions.AI`

Sentry.Extensions.AI is our drop-in instrumentation layer for .NET LLM packages that are based on Microsoft.Extensions.AI.Abstractions. You can instrument your LLM usage including:

LLM calls
Inputs and outputs
Token count
Model name
Tool calls input/output
Issues related to the LLM call
Total cost

All of this is available to see in Sentry as spans and events, so you can correlate AI behaviour with the rest of your application: HTTP requests, background jobs, database queries, and more.

What is `Microsoft.Extensions.AI.Abstractions`?

The AI.Abstractions package is a low-level contract layer for many other libraries. It contains pure interfaces and data models for generative AI in .NET. It is intended for other libraries to implement. It has minimal dependencies so it can be the base for this ecosystem of libraries.

This is not to be confused with Microsoft.Extensions.AI, which includes utilities such as ChatClientBuilder, and built-in capabilities such as logging and tool invocation. The relationship between the abstraction package and Microsoft.Extensions.AI are very similar to the relationship between Microsoft.Extensions.Logging and its abstraction package.

Building our agent monitoring around Microsoft.Extensions.AI.Abstractions allow our users to use any LLM library they want, as long as they implement IChatClient from the abstractions package. For example, our ASP.NET Core sample project uses Microsoft.Extensions.AI.OpenAI , which provides us with IChatClient implementation with OpenAI APIs. One can just as easily swap out which LLM it is using by using a different library with IChatClient implementation.

How it works

Sentry.Extensions.AI works by wrapping your existing IChatClient and tools, so that every LLM call and tool invocation is automatically instrumented without changing your application logic.

In code, it looks roughly like this:

AddSentry wraps the OpenAI IChatClient, and AddSentryToolInstrumentation instruments tool calls. We intercept requests and responses, measure how long operations take, capture token usage and errors, and then pass everything through to the underlying client so the behaviour of your app doesn’t change.

Most of the work in this library was about doing that as transparently and cheaply as possible, while still handling tricky cases like streaming responses and multi-step tool-call loops.

Handling streaming responses without breaking error handling

One of the trickiest parts was instrumenting IChatClient.GetStreamingResponseAsync, which returns an IAsyncEnumerable<ChatResponseUpdate>. I wanted to:

Wrap the streaming loop with Sentry spans
Keep overhead minimal
Catch any exception thrown while fetching the next token, record it, and still re-throw it to the caller

But C# doesn’t let you yield return from inside a try/catch that needs to cover MoveNextAsync, and using foreach would implicitly wrap MoveNextAsync and yield return together.

The solution was to work with the async enumerator directly and separate the logic between advancing the stream and yielding the value:

By calling MoveNextAsync() inside the try/catch and doing yield return afterwards, we can:

Preserve the original streaming behavior
Capture any exceptions thrown by the provider’s enumerator
Enrich and finish our spans once the stream ends or fails

The result is full visibility into streaming responses with essentially no extra overhead for the caller.

Capturing the whole tool-call loop in a single span

Another challenge was capturing one span that represents the entire “LLM + tools” loop, not just individual model calls or tool invocations. In the screenshot below, you can see that one span is a parent of all these other spans. This is what we call an agent span.

The agent span shows the duration of the whole LLM interaction, including any tool calls and text generation. It also contains the original input and the final output.

When you use the FunctionInvokingChatClient — or UseFunctionInvocation — from Microsoft.Extensions.AI, the LLM call flow looks roughly like this:

We wanted one span that covered this entire loop. From the first LLM call, through all tool calls, to the final response. The problem was FunctionInvokingChatClient lives in Microsoft.Extensions.AI, not in Microsoft.Extensions.AI.Abstractions, and my instrumentation is built around the abstractions layer. There was no obvious hook at the “whole loop” level.

The workaround was to piggyback on FunctionInvokingChatClient's existing telemetry:

FunctionInvokingChatClient starts an Activity when its tool-call loop begins and stops it when the loop finishes.
We created an ActivityListener that taps into the Activity, with its ActivityStarted and ActivityStopped callback functions set to create Sentry spans.
Inside that span, we still record the individual LLM calls and tool calls as child spans.

This gives us exactly what we wanted. A single top-level span that represents the full agent/tool orchestration, without needing direct access to FunctionInvokingChatClient from the abstractions layer.

Future of Agent Monitoring in .NET

Because Microsoft.Extensions.AI.Abstractions sits at the base of many AI libraries, this integration is just the beginning.

Microsoft’s new agent framework, Microsoft.Agents.AI, builds on these abstractions, and so do other higher-level frameworks like Semantic Kernel. That means the same concepts we use today for instrumenting raw IChatClient calls can be extended to:

Track multi-step agent workflows
Visualize tool and plugin orchestration
Add observability to Semantic Kernel pipelines, planners, and skills

Our goal is for Sentry.Extensions.AI to become the standard way to monitor .NET AI workloads — whether you’re calling a single model directly or orchestrating complex agentic systems on top of Microsoft.Extensions.AI.Abstractions.

Meet Web Vitals Performance Issues

Mon, 08 Dec 2025 00:00:00 GMT

We’ve introduced a new type of Performance Issues, Web Vitals Performance Issues. These issues will be opened for the highest opportunity pages in your application if your Web Vitals metrics drop into our meh, or poor thresholds for performance.

We’ve built these issues with Seer Issue Fix specifically in mind. Our goal is to not just alert you about low vitals scores, we want to give you actionable steps you can take to improve your scores and, when possible, fix the problem for you.

What are Web Vitals, and why should you care?

Web Vitals are standard metrics for understanding how your site’s user experience compares to benchmarks for performance. A website with good vitals scores isn’t guaranteed to have a great user experience, but a website with bad vitals is — most likely — a bad user experience.

But hey, even if you don’t care about providing a delightful user experience, Web Vitals can affect your ranking in Google’s search, your listings on Shopify, etc. tldr; they affect your bottom line 🤑.

The three Core Web Vitals (the ones you should care about most) are:

Largest Contentful Paint (LCP): How long does it take the largest element on your page to render? Measuring loading.
Interaction to Next Paint (INP): When interacting with a page element, how long does it take the next frame to render? Measuring interactivity.
Cumulative Layout Shift (CLS): How much do elements shift during pageload? Measuring page stability.

Web Vitals and Sentry

Sentry already has a great out-of-the-box dashboard for measuring Web Vitals metrics across your application — we talk about the feature here, and here, and also here.

Here are some things some things that make Sentry’s existing Web Vitals functionality cool:

We collect metrics from real user sessions. As developers are well aware, things usually run perfectly on your own computer.
We collect metrics for authenticated pages without additional hoops to jump through.
You can see your Web Vitals performance in the context of other telemetry — maybe a page was slow to load because an exception was thrown and an operation retried.

Today we’re releasing a slick update to Sentry’s built-in Web Vitals features, Web Vitals Performance Issues.

Introducing Web Vitals Performance Issues

Web Vitals Performance Issues are a new type of Performance Issue that will be triggered when the highest traffic pages of your application are exhibiting poor vitals metrics for an extended period of time.

In my opinion, the killer feature? With Sentry’s Seer Agent, these issues won’t just warn you about a bad score, they’ll help you root cause and actually fix the underlying problem.

Why didn’t we do this sooner?

Up until now, we opted not to alert users about poor Web Vitals scores (even though Performance Issues aren’t new), what was preventing us?

We didn’t want to create busy work for developers. Although important, poor Web Vitals measurements are secondary to signals like errors in an application.
We didn’t want to spam users with a alerts. A bad Web Vitals metric may be a problem across dozens of pages.
We didn’t want to create issues that weren’t actionable. “Okay, I have a bad CLS score, now what?”, we imagined users asking.

Here’s how the approach we’ve taken addresses these concerns…

Avoiding spam and busy work

We’ve taken a few steps to avoid overwhelming engineers with a wall of Web Vitals issues:

Issues are created at a lower priority than critical errors, so they can be filtered out of the issue stream.
Issues are only opened for the top 5 highest opportunity pages.
We only reevaluate Web Vitals scores every two weeks, and won’t open new issues for the category of problem for the same page.
With Seer Root Cause Analysis, we hope that we can give developers a helping hand fixing poor Web Vitals scores (not just alert them).

Making issues actionable

How are we making sure these issues are actionable?

We’ll only open Web Vitals issues if you have Seer enabled on your account. We didn’t want to create alerts without also helping you fix them.
We attach various signals to the Web Vitals issues, making it possible for our AI agent to root cause and fix the problem:
- Seer has access to the codebase exhibiting the poor web vitals score.
- Seer has access to traces representing typical user sessions on the page.
- Seer has access to the historical Web Vitals metrics for the given page.

Wrap things up already…

It’s my hope that, with some of these design decisions we’ve made, we’ve built something that:

Will truly help people better diagnose and fix gnarly performance issues on their websites.
Won’t introduce annoying new tedium to engineers that makes them want to throw their laptop out the window 😅. Note, if you do find yourself wanting to throw something, the feature can be turned off here.

Read more about Web Vitals Performance Issues in our documentation, and please be liberal with your feedback.

AI updates for all Sentry users

Thu, 04 Dec 2025 00:00:00 GMT

Instead of giving you yet another chatbot, we built AI straight into the parts of Sentry where teams lose time, turning your existing data into instant context — and it’s now available to all Sentry users.

Just ask your question with natural-language queries in Trace Explorer

Trace Explorer now accepts plain-language questions and turns them into real queries. Instead of remembering operators or field names, you can describe what you want directly.

A question like “What’s the p90 latency of my DB?” generates the underlying query, identifies the relevant spans, and surfaces the latency distribution without requiring you to write any syntax. You get the same depth of trace data as before, with much less effort spent forming the query.

Get a first take on what’s causing an issue

When you hit a new issue, the first question is usually “Where do I start?”

Initial guess - located on each issue - automatically runs an initial analysis of the issue context to determine what the problem could be. It provides a starting point for you before running a deeper analysis with Seer, which looks at your source code and additional Sentry telemetry to more accurately determine the root cause.

Get to the insight faster with Session Replay Summaries

Jumping to the moment an error occurred is useful, but understanding how the user got there still takes time. Long sessions often involve dozens of interactions, network calls, or UI states that matter but aren’t visible from the error timestamp alone. Replay Summaries analyze the replay’s metadata—DOM events, network requests, console logs—and generate a short explanation of the events that actually contributed to the failure, along with time stamps linking you to each event.

For example, if a user clicks the checkout button, sends a request that returns a 500, and your frontend fails and shows the user an error state, the summary will combine these into a single narrative:

Head to Explore > Replays and click into a specific replay to see the AI summary tab.

Translate frustration into something you can actually use with User Feedback Summaries

User feedback is helpful, but reading it at scale is slow and often inconsistent. People describe the same issue in completely different ways, mix in frustration, or focus on symptoms rather than what actually went wrong. Located at the top of the User Feedback view, user feedback summaries process all incoming feedback and generates a concise, high-level explanation of what users are collectively experiencing across the projects and date ranges you have selected.

The system looks across every submission in your project and identifies the dominant themes: what users were trying to do, what failed, and how those failures cluster. You can still dive into specific submissions when needed, but you no longer have to manually read and categorize them to understand the broader problem.

Bring Sentry context into your AI tools with Sentry MCP

Context switching takes you out of flow and disrupts your thinking, so we created an MCP server that lets you interact with Sentry data without leaving Cursor, Claude Code, Codex, or your favorite client. Sentry’s MCP can access data about your organizations, projects, teams, issues, errors, releases, performance and more.

For example, you can ask it to identify and fix the most critical issue in a given project, as shown here. Sentry’s MCP identifies a missing null check that would cause a 500 error. It shows what’s broken and why, and implements the fix, all through Cursor.

Less hunting, more fixing

These updates are available today for all Sentry users. You can try them directly and we’ll continue improving them as we get more real-world usage and feedback. Give it a try and let us know what you think.

<100ms E-commerce: Instant loads with Speculation Rules API

Mon, 24 Nov 2025 01:00:00 GMT

In e-commerce, we all know that speed = money. I know it, you know it, Amazon knows it, eBay knows it, Shopify knows it, everyone knows it. In this article we’ll see how we can improve the perceived performance of our site’s critical pages, like the Product Details page, the Cart page, the Checkout page. We’re going to use the Speculation Rules API (SRA) to prerender/prefetch them, and also explain how certain frameworks like Next.js offer their own prefetching mechanisms.

Speculation Rules API

The SRA is an experimental feature available only in Chromium browsers that allows websites hint to the browser which pages a user is likely to visit next, so the browser can start either preloading or prerendering them ahead of time. This makes navigating to those pages feel instant.

prerender rules make the browser fully download, render, and load them in an invisible tab. This will load all subresources, run all JavaScript, and even perform data fetches started by JavaScript. Navigating to a prerendered page is instant. It’s literally the browser “switching tabs” to a completely loaded page.

prefetch rules make the browser download the page’s document only. It doesn’t render the page in the background, or execute any JavaScript, or load any subresources. It just skips the main document HTTP request upon navigation, but the page will still need to be rendered, and resources loaded. This still leads to major performance improvements, but it’s significantly lighter than the prerender rules.

These rules are added on the page through a <script type="speculationrules"> element, and are defined with JSON:

The speculation rules above will prefetch all of the /products/* matching URLs that are present on that page eagerly, and also the /cart page. It doesn’t matter how you add these rules - you can hardcode them at the bottom of the <head>, or you can dynamically generate them with JavaScript at runtime. There’s no “deadline” for adding these rules. The browser will start prefetching/prerendering the moment it sees them in the DOM.

There are options for the eagerness, different types of matchers and selectors, and other gotchas, and we won’t cover them in this article, so make sure to check out the official Speculation rules API doc on MDN.

Speculation rules API fallback for different browsers

Since SRA is only available in modern versions of chromium-based browsers, our Safari and Firefox users will miss out on that love. But there’s still something we can do for them too. We can’t really replicate the SRA functionality, but we can leverage the framework-specific prefetching feature that most modern frameworks provide. Usually it’s in a form of a prop or element attribute that you set to a link that makes the framework prefetch that page either on page load, on hover, or skip prefetching it altogether.

Most of the frameworks automatically prefetch pages either on page load, or as they get scrolled in. For example, both Next.js (docs) and Nuxt 3 (docs) prefetch pages by default. SvelteKit (docs) and Remix (docs) do not by default, but give you options to define prefetching. Visit the docs links of your framework of choice to see how you can configure prefetching.

Having framework-level prefetching enabled is a great fallback because it still improves the navigation performance of non-chromium browsers, but also won’t hurt chromium browsers. In case where a chromium browser loads a page with both speculation rules and framework-specific prefetches, the speculation rules will take precedence. For example, let’s say all /product/* pages are prefetched through speculation rules, but on hover as well. When the user lands on the page, the speculation rules will make the browser prefetch all product pages and cache them, so when the user hovers on one of the products the browser won’t prefetch it again since it’s already in cache.

How SRA improves storefront performance

To put all of this to a test, I developed (ahem, vibe coded) a demo Next.js storefront and instrumented it with Sentry’s Next.js SDK. The SDK automatically measures page loads, but to distinguish the prerender metrics from the prefetch ones, I needed to just add a tag with the value of the optimization mode whenever it changed:

After this, all I needed to do is create a custom widget that charts the navigations grouped by the optimization method:

(widget specs - spans dataset, p90 of span.duration visualization, filter: span.description contains /products/:id and span.name contains navigation, grouped by optimization_mode)

And look at that! Quite the difference between prefetching/prerendering and no optimization at all. No optimization also means the framework-level prefetch is disabled. This data is obtained from a Vercel deployment, triggered by an automated script. Even on my painfully simple demo app the improvement is significant. I would anticipate the improvement to be much bigger on a real e-commerce storefront with tons of other features like analytics, widgets, all sorts of scripts.

Now from this chart we can’t really say for sure that prerendering is faster/better than prefetching, or vice versa. But one thing is for sure - any optimization is times better than no optimization at all. I would encourage you to set up Sentry’s Next.js SDK in your application to measure and see the difference in your app. Your values will definitely look different than mine above, and the difference between prerendering and prefetching could be more obvious.

Speculation rules gotchas

The SRA does not represent a free performance boost. Just like anything, it comes with some caveats that you should be mindful of. Here are some of them:

Server load and bills

When prerendering, we’re running full SSR + data calls even if the user never clicks on those pages. To fix this, prefer prefetch over prerender, use prerender sparringly, only for links of highest following probability.
If there are many links in the viewport, there are going to be many prefetches/prerenders. This is a classic thundering herd scenario. To fix this, use conservative eagerness in SRA, and set prefetch={false} on low-prob links.

Analytics / experiments

Since prerendering also invokes all JavaScript on all of the prerendered pages, that means analytics SDKs will also be invoked, resulting in inflated pageviews / conversions. To fix this, you can fire analytics events on activation - check document.visibilityState === 'visible' after the visibilitychange event, or if you’re doing analytics on the server-side, set a Speculation Rule Tag and look for that header, or the Sec-Purpose header.
If you’re also running A/B tests, you’ll experience results skew as well. To fix this, assign experiments on activation, defer experiment beacons until visible.

Product behavior quirks

Prerendering may use current cookies. Tokens can expire before activation, which will result in an auth mismatch / stale session. To fix this, use short-lived cookies, refresh on activation.
Various side-effects during render, like inventory holds, impressions, “last seen” tracking, etc. To fix this, make SSR/data idempotent + read only, and move any side-effects to activation or click.

This is far from an exhaustive list of prerendering/prefetching gotchas, so make sure you do your due diligence - profile real traffic, monitor server load, verify analytics accuracy, and test under production conditions before you roll it out broadly.

Speculation rules in your application

Now that we know the benefits and caveats, let’s talk about how to use the Speculation Rules API in a balanced and strategic way.

We know that prerendering is heavier than prefetching, but it does more of the loading upfront, which should result in better performance. With that in mind, we should use prerendering sparingly. In an e-commerce storefront scenario, I would use prerendering only on a smaller products section, like a “Featured products” section at the top that lists at most 4-5 products, or on event-based sections like a Black Friday banner that’s too good to pass on. These types of sections usually have big CTAs and draw more clicks to them.

Prefetching on the other hand is lighter, but still an important optimization approach. I would use prefetching on other less important (but still important) product cards, or category pages linked in a navigation bar. I would even configure the prefetch to be on “hover” instead of page load just to be safe. If the Black Friday section is first-class, these would be second-class. Prefetch them, but be mindful of how many pages you’re prefetching (unless you prefetch on hover).

For all the other pages that aren’t that important, you can either disable the framework-imposed automatic prefetching to ease up your server load and bills, or keep hover-only prefetching.

Make sure to use prerendering on the critical flow - the flow that “makes money” - user lands on homepage, visits a product, adds to cart, goes to checkout... Strategically placing prerendering rules on pages on this flow will significantly improve the performance of the critical flow, and result in more conversions, more checkouts, more money spent on your website. That’s what you ultimately want, right? With the Speculation Rules API, you can be really smart about this.

Most importantly, make sure to keep an eye on the performance in production after you deploy the improvements. Set up Sentry in your project, and create a Critical Experience Monitoring Dashboard that gives you an overview of how the critical flow is performing, and if you need to improve a certain part of it:

Bringing it all together

In this article we saw how the Speculation Rules API (and framework-level prefetching) can drastically improve the perceived performance of your e-commerce storefront by doing the loading upfront. We used Sentry to measure the performance boost in a production environment and concluded that prerendering/prefetching pages significantly improves the page load performance compared to no optimization at all.

But all that improvement doesn’t come without gotchas. We saw how SRA / prefetching can increase your server load, skew your analytics, and even prerender pages with stale auth cookies. Nothing to be afraid of though! If you have eyes on your app in production (ahem, use Sentry) you can react fast and fix any issue before it affects a large number of users.

Eliminating N+1 Queries with Seer’s Automated Root Cause Analysis

Mon, 24 Nov 2025 00:00:00 GMT

When I was working at Shopify, major traffic moments were our Superbowl. We initiated code-freeze weeks before to make sure merchants wouldn’t have any unexpected issues during one of the most important times of the year. Sometimes, though, you need to ship updates last minute.

Picture this: It’s 11:47 PM on the day before your massive sale goes live. You’ve just deployed a new /sale page with 50+ products at discounted prices. Marketing is about to email 500,000 subscribers. Everything tested fine with your sample data.

At 12:13 AM, you get your first Sentry alert.

The problem

Your /sale endpoint is averaging 4+ seconds per request. Users are experiencing timeouts. You need to fix it now.

Sentry catches the problem

You open Sentry and see it's already identified the issue: N+1 Query. Sentry automatically analyzed your transaction spans and found that your /api/sale endpoint is making 150+ sequential database queries per request.

The issue details show the characteristic pattern: one initial query to fetch all products, followed by repeated queries for each product's sale price, metadata, and category information. Classic N+1.

You implemented it this way because it was straightforward: get all products, then loop through and fetch their sale data. It looked clean. It worked perfectly with 5 test products. But with 50 products on sale? That's 151 queries per page load.

Using Seer

You open the issue in Sentry and click "Find Root Cause"

Seer analyzes the trace data and your codebase, then provides a root cause analysis:

Sequential database calls inside a product loop create an N+3 query pattern, resulting in 54 queries and 10+ seconds latency.

Seer pinpoints the exact code:

The fix

You ask Seer to generate a fix. It provides an optimized solution:

One query instead of 150. You approve the fix and Seer opens a pull request with the changes.

You merge and deploy. P95 response times drop from 7 seconds to just under 2 seconds with P50 scores going from 3 seconds to 275 milliseconds

The difference

The entire process from "something's wrong" to "fix deployed" took 6 minutes:

Automatic Detection (0 minutes): Sentry identified the N+1 issue as soon as it happened
Root Cause Analysis (2 minutes): Seer analyzed the trace data and pinpointed the exact problem
Solution Generation (1 minute): Seer provided production-ready code with proper SQL joins
PR and Deploy (3 minutes): Review, merge, and ship

Without Seer, you’d spend hours digging through traces and logs. And when user traffic is surging, every minute spent debugging is one your users spend waiting.

Seer didn't just identify the problem, it explained the pattern, showed exactly where it was happening, provided production-ready code, and opened a PR.

Why it matters

During high-traffic moments or key launches, slow debugging is expensive. When users are experiencing issues, you need answers fast.

Seer provides those answers. It analyzes your performance data, explains issues clearly, and generates concrete solutions. It combines Sentry's automatic issue detection with AI-powered root cause analysis and code generation.

The next time you hit a performance issue during a critical moment, Sentry will catch it and Seer can help you fix it.

See how Seer could fix your next N+1 issue before users notice. Learn more about Seer and get started with AI-powered debugging.

Seer can now trigger Cursor Agents to fix your bugs

Thu, 20 Nov 2025 00:00:00 GMT

We just launched our Cursor Cloud Agent integration. Now when Seer finds a bug, it can hand it off to Cursor—replete with all the context Sentry has about the issue—to write the fix and create a PR for you.

Fully automated, validated, code fixes

You can now autonomously run a coding agent within your full running codebase environment, all in the background.

When Seer detects and analyzes an issue to find the root cause, it can now send the root cause and the issue context to a Cursor Cloud Agent. The agent gets:

Full issue context: stack traces, breadcrumbs, user impact, the works
Seer's Root Cause Analysis: our deep analysis into what actually broke
Your running codebase: the Cursor Cloud Agent has your full running codebase, and can run your code

Then it gets to work. Autonomously. While you grab coffee.

You’ll come back to a ready pull request made by the agent in your repo.

Two ways to use it

Manual trigger

From any issue's Seer Root Cause Analysis card, click the dropdown next to Find Solution and launch a Cursor Cloud Agent. Perfect for when you want to delegate specific bugs.

Automated workflow

Set up Seer Automation to auto-trigger Cursor for certain types of issues. Configure this in your Seer settings by selecting Cursor Cloud Agent as the stopping point. Now your most critical (or most annoying) bugs get queued for fixes automatically.

What can you do with it?

We’ve seen a lot of people copy our Root Cause Analysis to local Cursor agents to continue to debug. Now, you don’t have to copy paste as Cursor Cloud Agents will show up in your agents tab on your local Cursor IDE for you to iterate on and help your debugging workflow.

Also, because Cursor Cloud Agents spin up with your fully working code environment, it can run type checks, lint, and tests. With this, you can get issues automatically triaged and merge-ready.

Get started in 3 steps

Setting up takes a few minutes:

In Sentry, navigate to Settings > Integrations and find Cursor Agent
Click Install and provide your Cursor API key (find it in Cursor Account Settings under Integrations >User API Keys)
Go to Settings > Projects > [Your Project] > Seer, then configure your stopping point to be “Hand off to Cursor Cloud Agent”

Now, you will start seeing PRs from your Cursor Cloud Agent popping up on your repos.

Check out the docs for more. And if you're new to Sentry, sign up for free to get started.

The metrics product we built worked — But we killed it and started over anyway

Wed, 19 Nov 2025 00:00:00 GMT

Two years ago, Sentry built a metrics product that worked great on paper. But when we dogfooded it, we realized it was not what our customers really needed. Two weeks before launch, we killed the whole thing. Here’s what we learned, why classical time-series metrics break down for debugging modern applications, and how we rebuilt the system from scratch.

Why our first metrics product was not good

We set out to build a metrics product for developers more than two years ago–before I even joined Sentry. We ended up following the path most observability platforms take: pre-aggregating metrics into time series. This approach promised to make tracking things like endpoint latency or request volume efficient and fast. And our team succeeded; tracking an individual metric was fast and cheap.

But we have a culture of dogfooding at Sentry and as we started to put the system to real use, we started to feel the pain. It’s the same problem that plagues every similarly-designed metrics product: the age-old Cartesian product-problem. If you didn’t know, in traditional metrics, a new time series needs to be stored for every unique value of an attribute you add (e.g. for every individual server name you store under the “server” attribute.) And if you want to do multiple attributes, you need to deal with every combination of values. All of this comes from the fundamental issue that when you are pre-aggregating you need to define your questions up front.

Now sometimes this isn’t a big issue. If you’re just tracking memory usage on 30 servers, or CPU% of each of the 16 cores on those servers, it’s all good.

But the problem is that Sentry’s goal is to give developers rich context to debug and fix code when it breaks. To this end, we know developers love to add lots of context/attributes to make it easier to understand what’s going on. But when the extra context explodes the cost, it incentivizes developers to not track all the context they want. Our engineers dogfooding our product continuously found themselves stuck between a rock and a hard place… Not good.

Cardinality is a harsh mistress

Let’s look at an example. Assume that each individual time series costs $0.01/mo. (That’s the right order of magnitude for the industry.) And let’s say you are tracking the latency of a specific endpoint called 100,000 times/day. Reasonable situation. Now let’s say one developer is interested in which (of 8) servers it’s being served on and adds an attribute for that. And another is interested in which (of 200) customer accounts it’s for. Then another wants to know which (of 12) sub-request types it is. Then the kicker–a developer wants to know which (of 5,000) users it’s for. I’ll take your guesses for what the cost is up to… OK, did you guess ~$1M/mo? Yes, that’s the real number.

And, honestly, this is an easy example. It’s not unusual for a developer to want to capture 10-20 attributes.

Of course you can play games like trying to avoid certain combinations of combined filters to keep things in check, but the management of it all is a pain. Long story short, we became convinced that we were about to ship a bunch of painful tradeoffs to our users that would make it hard for them to succeed–especially for Sentry’s mission of providing the richest possible debugging context. And ultimately it was me, just two weeks before our planned ship date (and two weeks after I joined), who decided to pull the plug on the product. I was not popular.

Didn’t we see this coming?

I know what you’re saying: Are you guys dumb? Surely this was totally predictable. You’re right. When we started the metrics project, there were significant debates up front. And indeed, the original vision was about trying to connect our metrics to the existing tracing telemetry that our users have. But in a series of scope drifts, bad communications, and fears about cost structure and being different, we ended up making some sacrifices. It was a painful lesson we had to re-learn: When building a new product you have to make sure to be very clear up front about the vision, and diligent that you’re not compromising or straying from it as you build.

Why was the vision “trace connected”?

Wait, you just said the problem was cost blow up. What’s this about connecting to traces? Well, dear reader, the problems with v1 went even deeper…

Let’s put aside all considerations about cardinality and cost. Assume infinite compute. The other problem with time series is that taking a bunch of increment() or gauge() calls in your code and aggregating them to 1 second granularity sucks, because it destroys the connection between data and code. You can graph the metrics over time, sure, but that graph lives in a parallel universe. It is connected to your code (and your traces, logs, errors, etc.) only indirectly via timestamp.

And that’s a problem, because, again, our goal isn’t to give developers dashboards, it’s to give them context—direct, actionable, connected context—so when something goes wrong, they can see why.

Correlating indirectly via timestamp simply doesn't do that very well. You look at a spike in latency, or an increase in error rate, and then jump over to a separate system, hunting through traces or logs, trying to reconcile timelines. This kind of “roughly around that time” debugging makes you pull your hair out, and is the (other) achilles heel of traditional metrics.

Can our customers afford the best?

So what would a system look like that didn’t blow up in cardinality, and didn’t aggregate to 1 second granularity?

Dave, you say, I know where you are going, and it sounds expensive… Yes, let’s talk about what it costs to keep all the raw data and aggregate it on the fly, and the tradeoffs.

But, first, a bit of context: most observability and analytics systems have moved away from pre-aggregation and toward raw-event storage with on-demand aggregation. This has been enabled by cheaper storage, massively parallel compute, and the rise of columnar query engines. It’s been a mega trend that started in the early 2000s with Hadoop, and has slowly swept across the industry ever since. Logs, tracing, BI (do you remember OLAP cubes?), even Security are all domains where early tools relied heavily on pre-defined aggregations and now almost exclusively store raw data and analyze it on demand. Is it metrics’ time?

Let’s use the previous example for endpoint latency. Sorry, more math… Let’s say that the attributes we used in the example above (server, customer, sub type, user email) amount to 250 bytes of raw data. And, let’s just use the price of Sentry logs as a cost proxy ($0.50/GB/mo). At the stated rate of 100,000 times/day, we are talking a cost of, drumroll… $0.37/mo. Yes, that’s right. It’s way more ($0.36/mo more) than it costs to track an individual time series, but way less (~$1M/mo less) than if you wanted to track those four attributes too. The lesson is: though your metric vendor’s sales rep thinks otherwise, you really don’t want to be on the wrong side of an exponential.

Now, the astute among you probably realize that the 100,000 times/day is a key variable here as well. Traditional metrics don’t scale in cost with this metric, but raw-data based metrics do. So, if you have a metric that fires 1M, or 10M times per day, we’re talking about $3.70, or $37/mo if you want to keep everything. Which is a lot for 1 metric, but honestly, if you have an important user-facing endpoint firing 10M times per day, congratulations! And if you want to limit costs, you can always sample (my personal go to), or just find a higher-level aggregate counter to log.

What’s that, you hate sampling or anything lossy? Well, I hate to break it to you, but if you have an endpoint firing 10M/day, it’s firing 100+ times per second on average, and that 1-second-bucket time series is already aggregating a ton of detail away anyway.

Starting over with trace-connected telemetry

Back to our story. We pulled the plug. The next steps were straightforward, but ended up taking us a while. We went back to the drawing board to build event-based metrics.

That decision actually led to a much deeper rearchitecture at Sentry—and the creation of a new, generic telemetry analytics system we internally call the Event Analytics Platform (EAP). It’s based on ClickHouse, which is an excellent modern columnar store. We’ve given a couple of talks about it, but this work probably deserves its own blog post. We first used EAP to power-up our existing tracing product, building new slicing and querying capabilities. We next used it to deliver our recently-shipped logging product. Now, more than 18 months after pulling the plug on metrics 1.0, it’s backing our next generation Metrics product.

What’s new about Metrics this time around is that every metric event is stored independently in EAP and connected to its trace ID. This solves both the cardinality problem, and the connectedness problem. It means that we can slice and dice metrics dynamically and link them to other telemetry. It also means that you can keep adding more and more contextual tags, even ones with super high cardinality, without fear of blowing up costs.

Metrics with context

We’ve been back to dogfooding, and this time we’re pretty happy. The trace-connected model unlocks debugging workflows that weren’t possible before. Instead of jumping between dashboards and guessing at time correlations, you can follow the data directly:

See a spike in checkout failures? Jump from that metric to the exact trace where a failure happened; jump from the trace to an attached Sentry error.
Notice an increase in retries? Break down the metrics by span to see which service is at fault.
Watching p95 latency climb? Drill into the worst offenders and find related session replays to see what the user is experiencing.

Metrics about your application

What about Infra monitoring? Well, we expect some of our users will do it, but we’re not really pushing that use case for Sentry metrics. This point created a good deal of internal discussion since it’s so hard to decouple the idea of metrics from the idea of infrastructure. And time-series pre-aggregation is sooo tempting for infra because machine-level metrics are already disconnected from your code, and it could be cheap, and, look, this simple little daemon can slurp up all of these signals, and, look, charts!

I won’t lie, we use infra metrics, and we know they aren’t going away. But for us, metrics are much more powerful when they are application-level signals, connected to the underlying code that produced them. Traditional CPU and memory graphs have their place, but modern developers, especially ones building on high-level platform abstractions, care less about infra and more about higher-level application health: login failures, payment errors, request latencies. Those are the metrics that tell you what’s really happening to your users.

As we add modern metrics to our own product, we find that we are using the dashboards-of-1000-time-series a lot less, and I think you will too.

Built for Seer

Since I’m officially a CTO, I’d be remiss to go an entire blog without mentioning AI. And, even though some of our efforts were just getting going when we made the call to reboot metrics, it turns out it was the right call for our AI debugging ambitions as well.

If you don’t know, we have an agent we call Seer built into Sentry. It root causes issues, proposes fixes, and will do even more soon. Behind the scenes, Seer uses tool calls to traverse all of the connected telemetry in Sentry—errors, traces, logs, and now metrics. What we keep finding with our testing is that data volume (a million examples) isn’t very important to make Seer debug well, but every additional type of connected data pays huge dividends. So, by making metrics first-class citizens in our telemetry graph, we ended up giving Seer a lot more connected context to work with.

I think this was a good demonstration for our team of the importance of sticking to your original vision for something. The original “make it all trace-connected” really did pay dividends vs. just shipping a traditional metrics solution as a separate feature, and even for a feature we hadn’t fully envisioned at the time.

The long road was worth it

If you’re reading this, you probably know how hard it is to kill a product you’ve already built. It’s harder still to admit that what you have, while functional, isn’t right. The sunk cost fallacy is a mighty foe. And I’m really sorry to all of the beta testers who were enjoying metrics v1, but we’re convinced the wait was worth it for the new version.

So, this wasn’t exactly a traditional marketing blog post announcing a product, but since we’re taking a different tack on this one, I thought it would be interesting to share the thought process. I hope you get a chance to try our new metrics product as we continue to build it and improve it, and hopefully this story also gives you a little inspiration for your own software projects to not be afraid to make the tough calls.

Introducing Logs, User Feedback, and more in the Sentry Godot SDK

Tue, 18 Nov 2025 10:00:00 GMT

With the first stable releases out of the gate, we’re happy to announce that Sentry’s Godot SDK is now ready for general use, supporting Windows, Linux, macOS, iOS and Android. We started full-time development a year ago with just a few prototypes, and now it's finally here - built on top of the mature Sentry platform SDKs, it comes as a GDExtension add-on that you can easily add to your Godot projects.

If you’re new to Sentry, it’s an application monitoring software that helps you manage your game's health during development, QA and after release. It can automatically track crashes, runtime errors, logs, and even player feedback so you can spend less time chasing bugs and more time creating awesome experiences. Keep reading to explore the key features in the Godot SDK.

Crashes and errors

Sentry gathers error and crash reports, grouping them into issues in a convenient dashboard, helping you prioritise which issues need fixing first. It automatically captures Godot Engine runtime and script errors showing detailed stack traces with optional local and member variables information and even surrounding script source context lines when available.

For crashes in C++ layer, Sentry can collect and send minidumps, letting you know when your game crashes and where in the Godot source code it happens. This information can help you understand the cause of the crash, and share the stack trace (or minidump file) with Godot developers, or even fix the issue yourself.

Bringing more context to debugging your game

There are almost infinite possible hardware configurations out there. Finding out why some players experience a bug that you can't reproduce locally can feel daunting. Sentry can help by giving detailed context about hardware and software your players are using, and every issue includes this information for the specific event, so you can see the exact configuration that triggered the problem. And that's not all - our SDK can send runtime logs, engine statistics, scene tree snapshots, and even in-game screenshots from the moment just before an issue is triggered.

Structured logs

Structured logs are now available in the Godot SDK as well, which means you can capture and link log output to crashes and performance issues in your game. The SDK can capture log output automatically: any time you print() in code or the engine spits out something, Sentry captures it in structured logs. You can then browse and search those log entries directly from the issue. So when a player gets stuck during a scene change or a crash occurs right after loading a resource, you’ll see the exact log trail leading up to the failure, available directly from the issue or trace view:

User feedback

We’ve also added User Feedback support, so players can share details about errors or just give general feedback on their gameplay experience. This means you can see real player insights alongside the usual technical details, helping you prioritize fixes and understand the player experience beyond the stack trace. There's a ready-to-use User Feedback UI in the addons/sentry/user_feedback folder that you can use or customize to your liking. Here's what it looks like in action:

Of course, if you want to get creative, you can build your own interface and submit feedback from code using our API:

Testing improvements

While preparing the SDK for general availability, we also didn't forget about testing. Our biggest achievement in this area was adding deep validation of event JSON content, which already helped us iron out small inconsistencies between platforms and catch several bugs.

To make this possible, we built a GDScript module that adds a fluent API for sophisticated JSON content testing. It's important to start testing from GDScript, since this is how most users interact with the SDK's API. This approach increases our confidence in the release process, knowing that we have a good foundation for catching potential regressions.

This expressive syntax makes it easy to define precise expectations for JSON structures while keeping tests readable and concise. Testing output is also quite informative, showing which steps fail in the call chain, along with helpful bits of JSON content.

Major version changes

Every major release is an opportunity to look back and improve things. The biggest change is the redesigned SDK initialization process. Instead of relying on a configuration script with a somewhat unclear lifecycle, you can now simply initialize and configure the SDK manually whenever it makes the most sense in your game.

Now that you can initialize the SDK manually, our advice is quite simple: do it as early as possible! The best place to do that is in your project’s main loop script. We also took an opportunity to add a method for cleanly closing the SDK connection if it’s no longer needed. This rounds out our improvements to the SDK lifecycle.

Platform support and getting started

The Sentry Godot SDK comes with support for Windows, Linux, macOS, iOS and Android. Coming soon: support for Web and C# exports, as well as support for W4 console forks. Crash reporting for PlayStation and Switch is already supported by Sentry, no SDK needed.

To get started, you can download it from GitHub, and refer to the documentation here. Got any questions or feedback? You can reach out in Discussions.

If you’re new to Sentry, you can explore our interactive Sentry sandbox or sign up for free.

Introducing webvitals.com: Find out what’s slowing down your site

Tue, 18 Nov 2025 00:00:00 GMT

Developers don’t need another “run this tool, stare at a number, and feel bad about it” website. So we built something different.

WebVitals helps you analyze, optimize, and ship faster websites, all in one place. Built by the same folks who obsess over stack traces and slow queries, it connects the dots between performance metrics and what’s actually slowing your users down.

In one place, you can:

See how real users experience your site
Spot the biggest slowdowns instantly
Get clear next steps (no jargon, no guessing)

How webvitals.com works

Enter your domain, hit go, and we’ll take it from there. Under the hood, WebVitals runs a couple tool calls using the Vercel AI SDK:

One to Google’s PageSpeed API - To pull real user performance data from the last 28 days, so called CrUX data
One to Cloudflare’s URL Scanner - To detect your site’s technology stack

Those results get combined and analyzed to surface the stuff that actually matters. You’ll see what’s solid and where things could use a little love. Each report provides clear, contextual steps for improving your metrics, using CrUX data for additional guidance. CrUX data is the 75th percentile of metrics from actual usage data from real users.

The Core Web Vitals report

You get real, actionable insight into your Core Web Vitals:

Largest Contentful Paint (LCP) – how fast your main content loads
Interaction to Next Paint (INP) – how responsive your page feels when users interact
First Contentful Paint (FCP) – when something finally shows up
Time to First Byte (TTFB) – how long it takes your server to respond
Cumulative Layout Shift (CLS) – how stable your layout is (or isn’t)

Each metric page breaks down which browsers track it, what “good” scores look like, and why it matters. We even added motion animations (made with the Motion animation library, because why not) to make all that data a little easier on the eyes.

Why Core Web Vitals matter

Core Web Vitals are a reflection of what real people feel when they use your site.

If your page takes too long to paint, shifts around while loading, or lags when someone clicks a button, users notice, and they bounce. A slow site can hurt your more than just CWV metrics. It affects your search engine rankings, conversion rate, and in the long run your revenue.

These metrics turn vague “feels slow” feedback into measurable, fixable problems. They’re the closest thing to a shared language between your performance graphs and your users’ frustration levels.

Go deeper with Sentry

Tools like Google’s PageSpeed Insights and Lighthouse are great for public pages, but they don’t cover everything. Pages hidden behind logins like your authenticated dashboards, admin panels, or internal tools more often than not require other tools to examine, and that’s where Sentry enters the picture.

With Sentry’s Web Vitals dashboard, you can track performance across every page of your app, not just the public ones. Sentry has an SDK for just about every language/framework. You’ll see detailed breakdowns with real user data, so you can understand and fix what’s slowing you down.

For example, the following Next.js image gallery app has some performance issues:

It loads slowly and shows a blank page while the image data is being fetched. The hero image also causes a cumulative layout shift (CLS).

To fix these issues, you can quickly set up and configure Sentry in your Next.js application to start capturing performance issues by running npx @sentry/wizard@latest -i nextjs within your project, then follow the installation wizard, which guides you through the whole setup process.

Once you’re done setting it up, the Web Vitals page in Sentry is a great starting point for investigating poor Web Vitals and figuring out which pages are affecting your web performance the most.

The Performance Score ring summarizes the overall perceived performance of your app. The Core Web Vitals metrics make up the ring and show their relative weight and impact on the score. Hovering your mouse over a section of the ring shows you the score and opportunity for that metric.

The opportunity is the difference between the current score and the maximum possible score (which is 100) for that metric.

The Score Breakdown to the right of the Performance Score shows an area chart of your Performance Score over time, which makes it easy to track core web vitals over time and identify regressions. The filters at the top of the area chart let you filter by environment, time range, and browser type.

The core web vitals are shown below the Performance Score. The metric values are shown in seconds or milliseconds. The performance score is also displayed and color coded: good is 90+, meh is 50-90, and bad is below 50. The table at the bottom of the page shows the core web vitals per page.

Click on a page route in a table row to get web vitals for that page.

The table at the bottom of this page shows traces where the web vitals were measured as well as the source element for the largest contentful paint (LCP), which helps you find the lines of code causing the slowdown. You can filter by web vital or search for a specific trace.

Another issue you’ve noticed is that the website's homepage is taking a long time to load. This could indicate that your server is struggling to keep up with requests. Looking again at the Web Vitals page, you see that the page has a very low Time To First Byte (TTFB) score.

You can then navigate to the page summary for the home page, and use the Web Vital drop-down to show traces by TTFB score. Then open a specific trace by clicking on the appropriate link.

Looking at this trace, you can quickly see there is a two-second delay between the user sending the initial GET request and the response from the Page Server Component. TTFB is calculated from the following request phases:

Redirect time.
Service worker startup time.
DNS lookup.
Connection and TLS negotiation.
Request, up until the point at which the first byte of the response has arrived.

The trace is not showing any evidence of the first four phases, and so you can determine that it is the actual request phase that is taking the full two seconds. Selecting this phase and clicking “More Samples” will allow you to see other examples of the same action, and you will be able to compare the request times from other traces.

In this example, there is a suspiciously consistent two-second delay that can be observed on each one of the samples. This is because an artificial slowdown was added to the example web app using setTimeout(). In a production environment, this may be harder to diagnose, as there can be many reasons for a slow web server response, but tracing should give you a good idea of where to focus your optimization efforts.

Removing the artificial delay solves your TTFB issue, but to improve the performance of the image gallery app, you need additional fixes. First, you could minify the hero image using Tinify, and then replace the <img> elements with Next.js Image components and provide a width and height to prevent cumulative layout shift (CLS):

`Image` components could be used for the image gallery images as well, so that the images are lazy-loaded. This means that they are fetched and rendered only when they are close to entering the user's viewport.

The page could also be converted from a client component to a server component to avoid the data fetching being render blocking.

With those fixes implemented, the Core Web Vital metrics look a lot better than before:

You can see the improvement over time in the Score Breakdown chart for the images page:

Think of Sentry as the logical next step after tools like WebVitals. Web tools are great at giving you a quick overview, while Sentry shows you everything underneath, what’s happening, where, and why.

Try WebVitals out

Head to webvitals.com, test your site, and see how it stacks up. You’ll get fast, clear insights, and maybe even a few things to fix before your next deploy.

Then, when you’re ready to go beyond surface-level metrics, bring it home with Sentry. Because knowing your site is slow is fine. Knowing why, and also how, to fix it is better.

Sentry Blog RSS

Routing OpenTelemetry logs to Sentry using OTLP

Why you'd use OTLP instead of the native SDK

Guide prerequisites

Get your Sentry OTLP credentials

Connect your OpenTelemetry app to Sentry

Clone the starter app

Configure Sentry as the OTLP destination

Test the integration

Generate some logs

View the logs in Sentry

Explore log attributes

How OpenTelemetry logging works

OpenTelemetry SDK initialization

Emitting structured logs

Log severity levels

Adding rich attributes

OTLP vs native Sentry SDK

Setup and configuration

Emitting logs

Log levels

What's next

React Native SDK 8.0.0 is here

Changes you'll want to know about

App start error capture

Updated native dependencies

Updated minimum supported versions

Apple Platforms

Android

Upgrading to version 8

What about version 7?

If you're ready to upgrade

From random chunks to real code — wiring up Next.js source maps in Sentry

What actually happens to your code

Why dev tools show nice stack traces but Sentry shows chunks

Use Sentry for production, Spotlight for local debugging

Simulating a production build so Sentry gets your source maps

What Sentry does during the build step

Verifying that source maps are wired up correctly

Double-checking your Next.js and Sentry configuration

Where to go when you're still stuck

AI-driven caching strategies and instrumentation

Building a mental model for caching

✅ Cache if most are true:

❌ Don't cache (or be very careful) if any are true:

Finding caching opportunities in production

Backend pain (start here)

User pain (confirmation)

Cost pain (the long-term signal)

Example: a slow paginated endpoint

Applying and instrumenting caching

Monitoring and optimizing caches

AI-assisted cache expansion in production

Alerting on miss rate deviations

Where to go from here

Sentry acquires XcodeBuildMCP

Why this fits Sentry

What XcodeBuildMCP enables

Example workflow

How this fits alongside Apple's MCP tooling

Commitment to open source

Looking ahead

Size Analysis is generally available in Sentry

Automated monitoring in your CI pipeline

Reducing your app’s size

Getting started with Size Analysis

Watching everything is watching nothing: Sampling strategy for Sentry

Why not sample 100% of everything?

The basic dials: Static sample rates

Precision control: The tracesSampler

What’s in the sampling context?

Staying in sync with inheritOrSampleWith

Smart sampling with Session Replay

Custom useSessionReplay Hook

What about Logs?

Summary: Sampling telemetry at scale

Less code, faster builds, same telemetry: Turbopack support for the Next.js SDK

What we were doing before

What we do now

What this actually means for your builds

Precision control: The `tracesSampler`

Staying in sync with `inheritOrSampleWith`

Custom `useSessionReplay` Hook

The `beforeSendLog` function