Sentry Blog

Automated agent triage with Agent Tracing and Claude Routines

Thu, 13 Aug 2026 09:00:00 GMT

Every morning, before anyone on the team has looked at a dashboard, a Claude Routine has already read around 800 of the previous night's conversations from Seer, Sentry's AI agent for triaging and fixing errors. It flags the ones that look broken, and files tickets for anything new. By the time we sit down with coffee, the triage is mostly done.

The problem

Before this routine existed, checking on our agent's behavior meant a custom, one-off flow for pulling data out of our current eval system. Querying options were limited, so most of it came down to hand-rolling a parser for the raw JSON in each trace. Someone had to remember to trigger the analysis and do it manually. Automating this was an option, but we never got around to it due to friction. Plus, we wanted to send the data to the other tools we use day to day, and the current setup didn't have that kind of connectivity.

We were looking for a mix of things. Tool call failures, hallucinated outputs, latency spikes, agent loops that went on longer than they should have, and cost anomalies. All of the above, really.

We had three main goals. Improve reliability by cutting down tool errors, keep an eye on the long tail of unusual runs (the ones that were unusually expensive or made far more tool calls than a typical conversation), and sample the conversations that looked good to actually confirm they were good, not just assume it.

The Claude Routine

The routine runs each morning as a Claude Routine. It connects through the Sentry MCP (a Model Context Protocol server that lets Claude query Sentry directly) to run Agent Tracing queries, plus a handful of general queries, against the previous night's conversations. Each run works through the same steps:

Pull aggregate stats for the period i.e., how many conversations ran overnight.
Pull aggregate tool stats: i.e., how many tools had errors, and at what rate.
From that list of errored tools, sample some spans to see real examples and trends behind the failures.
Sample a mix of full conversations, both with and without tool errors, and judge whether the agent's final verdict actually matches its reasoning.
Pull in the Seer codebase itself for more context.
Roll all of that into a single report of new findings.
Search our Linear project for existing tickets, and file new ones only for what isn't already tracked.

The prompt behind it is intentionally plain to let the LLM handle most of the work and judgment. The routine queries Sentry directly through the Sentry MCP, so there's no extra tooling to set up. That's all it takes.

Use the Sentry MCP to look at the last 24hr of <product> conversations
and analyze the results. In particular look for errors that might be
happening during the <product_stage>, say if our tools are broken. But
also sample some success conversations as well to see if they look
correct with secondary inspection.

If you come across new findings/errors, record them in a Linear ticket
for the <linear_project> project.

The Sentry MCP handles pulling and filtering conversations. Claude handles the parts that need judgment: reading a conversation, sampling for trends, and deciding whether something is actually worth a ticket.

What this looks like in practice

Analyzed the last 24h of <feature> conversations (~445-551 total,
~11k tool calls). No verdict-quality problems found — spot-checked
several conversations and the agent's reasoning was well-grounded,
correctly downgrading when it lacked repo access rather than
fabricating.

Did find an efficiency issue worth tracking: ~21% of conversations
(83/400 sampled) hit at least one tool error, mostly self-corrected
retries. Root causes:

Search Code sometimes gets fed malformed repo_name values (e.g.
appending a monorepo subpath onto the real slug, like
"foo/bar/applications/integrations" instead of "foo/bar"), causing
"repository not found" until it retries.

 sometimes gets a guessed-wrong project_slug (e.g. "mobile")
before self-correcting on retry with the right slug + time window.

Two conversations showed 30-56s hangs before an opaque "internal
error" — a real backend latency signal, distinct from the guessing
pattern above, worth an engineering look.

Filed Linear ticket AIML-123 with full details, example conversation
links, and error-rate tables: https://linear.app/getsentry/issue/AIML-123

The repo-hallucination case above is a good example of what a typical flagged morning looks like. The routine's tool-error stats surfaced Search Code as having an outsized error rate for the period. Sampling a few of the underlying spans showed the same shape every time: the agent guessing at repo names, one after another, none of them landing. We pulled up the full conversations and it was the same thing every time. The agent had no idea which repo it was looking for.

Aggregate error rates alone wouldn't show this. Neither would reading one conversation at a time. It took both. And once we saw it, the fix was straightforward. Just give the agent the repo name instead of making it guess.

Lessons learned

Running this daily made the feedback loop fast enough that most fixes landed the same day we spotted them.

As for some best practices:

Sampling both success and failure conversations, not just the ones with tool errors, mattered more than expected. A conversation can complete without a single tool error and still reach the wrong conclusion — that only shows up when something (or someone) checks the reasoning against the verdict.
Keeping the prompt focused on judgment rather than data retrieval made the output far more consistent morning to morning. The Sentry MCP handles the querying, so the routine doesn't need to reconstruct trace-querying logic from scratch every run.

How to do this yourself

With Claude Routines this is very simple. First, make sure Agent Tracing is set up for your agent. Then, add a Claude Routine with a prompt similar to mine that tells it to use the Sentry MCP to find agent traces for your feature. Lastly, make sure the Sentry MCP Connector (and others like Linear) is configured and enabled for the routine so that it can correctly authenticate to Sentry. That's it! For a full walkthrough, see the step-by-step recipe.

What's new in Sentry Logs: The summer 2026 roundup

Tue, 11 Aug 2026 09:00:00 GMT

We got a little behind on updating our changeLOG, so we're dumping it all into this bLOG post instead. Think of it as one giant, retroactive changelog entry or, if you want to be dramatic about it, one massive prompt injection straight into your feed. Either way: here's everything that shipped for Sentry Logs this summer.

Would you rather listen to the team talk about what they built? Check out this video where Kyle and Josh talk about the latest updates on Logs.

Pin the log line that matters

Sentry now has log pinning, so the next time you spot something interesting, you can pin the log line so it stays put while you keep scrolling, streaming in new logs, or refining your search. Pins are also synced to URL state, so a pinned view is a real, shareable link for the next time you want to show a teammate exactly what you're looking at.

Export logs at scale

We overhauled logs exports to handle large volumes faster and let you customize exactly what you're exporting.

Now, exports go through a dedicated export dialog where you choose your row count and format up front, including a new JSONL option built for larger exports. The result is a faster export and considerably lighter on our servers, because we're no longer guessing at what "export everything" should mean.

And because exports of individual log rows now include full attribute data, not just what's visible in the table, they're more useful if you want to pull a batch of logs into your own tooling.

Exporting is also now aggregate-aware: if you export while viewing an aggregate (say, a count grouped by some attribute), you get those aggregates, matching what you were actually looking at, instead of always falling back to the raw underlying logs.

This isn't a logs-only improvement, either. The same underlying export capability is now available across Errors and Tracing.

Usability improvements for the log viewer

The logs page is faster now. A new, more constrained layout plus loading less data up front both add up to quicker load times. Beyond that, the rest of this is basically our bug tracker's greatest hits to make using Sentry Logs more delightful to use:

Filters in the trace view Logs tab. Previously, the Logs tab inside a trace had no way to filter at all. Now you can narrow down what you're looking at without leaving the trace.

Every matching search term gets highlighted, not just the first one that matches in a line.

The error instance now shows up inline in the logs table on an issue, so you can see the error and the logs around it together instead of cross-referencing two views.

Timestamp is now always visible in the log details panel, even if you arrived from a dashboard link where the timestamp column had been dropped from the table.

Multi-value search filters now show as individual chips, instead of one long comma-separated value. Previously, message contains abc,def rendered as a single confusing text blob. Now abc and def are separate chips.

Drag-to-zoom no longer wrecks your browser history. It used to write three history entries per zoom, so hitting "back" didn't take you where you expected. Now it's one zoom, one entry.

Logs chart enhancements

We also made some UX enhancements to our logs charts. In case you haven't noticed, a lot of it has to do with giving you more room on the screen for your actual logs:

Charts can now expand and contract, with a standardized button in the top-right corner. Expand a chart when you want more room to look at it; contract it back down when you'd rather have the space for your logs.
Y-axis ticks now scale with the chart's actual height, not your browser's viewport height. Resize your window and the chart stays legible instead of collapsing down to two ticks.
Chart hover tooltips are a lot less flaky and no longer immediately disappear if you have auto-refresh enabled.
We expanded the color palette for grouped series, so it's easier to tell apart what you're looking at when a query returns more than a couple of groups.

Scaling logs data with Sentry

For orgs sending hundreds of gigabytes or terabytes of logs, the hard problem was never storing the data, it was finding one specific line out of all of it: a needle-in-the-haystack search.

We put in frontend and backend work this quarter specifically to support that scale, including longer query timeouts with continuations and better handling around rate limits, so search stays usable even with a genuinely large volume of logs.

A couple of smaller fixes ride along with this:

release:latest filters now work correctly in Logs and Trace Explorer. They previously returned empty results in some flows, like saved dashboard widgets, which made it look like there was nothing to see when there was.
Rate limit errors say what they are. If you hit a throughput limit, the UI tells you that you're being rate limited, instead of surfacing a generic error that looks like something's broken. And there's a retry button now, so you don't have to refresh the entire page to try again.

Try it and tell us what you want to see next

We know a list of shipped features isn't exactly thrilling reading and if you made it to the end of our updates, thank you.

Don't forget, if something is broken, missing, or just annoying, we want to hear about it. Hit the product feedback button in-app, or reach our team directly at logs@sentry.io.

How we built an automated debugging workflow at Sentry

Thu, 06 Aug 2026 09:00:00 GMT

AI is going to generate a lot of code from here on out, and a lot of bugs along with it. You already know this. We've talked about it before. The bigger challenge is making sure you don't spend all your time fixing the broken code your agents write.

You're going to need a system that makes it easier to fix those issues for you and fortunately, there are a lot of solutions out there for building automated workflows.

Recently, we've been exploring ways to automate our debugging and issue triage process here at Sentry. We also thought it might be helpful to pass along some of our tips and learnings in case you want to try it yourself.

It all starts with knowing what's broken and why

If you're going to have AI resolve issues for you, you first need to know when issues come up. No surprise: we use Sentry a lot here at Sentry. We've instrumented our application to emit all kinds of signals and metrics, which gives us detailed insight into how things are running.

As you can imagine, that means our Issues page can get quite full, which creates a lot of manual work in triage. That's where we bring in Seer, our AI-powered debugging agent. We have Seer's autofix set up across a number of Sentry projects, like core Sentry, our documentation, MCP server, and CLI tool, and their corresponding GitHub repositories. We've also given Seer permission to find the root cause of an issue, write a plan to fix it, and open pull requests for us automatically. Your org might not be ready to trust the machines that far, and that's ok. You can control how far Seer goes before a human joins the process. Automation is all about creating less manual work for your engineers, not reducing the number you have.

Automatic PR generation is useful, but it raises another question: how do you know when there's a PR to review, and who should review it?

Creating a routine for review

The hard part of automation usually isn't the difficulty of the tasks, it's managing those tasks as they grow in scale. It's useful that agents can handle small work like writing a code fix, but their real value is the efficiency they create across a system. In our case, Seer is now generating a lot of new pull requests, so how do we make sure they get actioned without inventing a new role like Chief Delegation Officer? More agents.

When we kicked off this project, we had two focus areas:

Automate the process of creating a fix
Bring in an engineer when there's something for them to pick up

We have a Slack channel set up that notifies us whenever Seer opens a new pull request. This uses a new alert trigger we recently added. It's a general feed — about 90% of the posts are new-PR notifications, with the occasional conversation mixed in. Instead of going through each one by hand, we use a Claude routine. Here's how we built ours.

Runs on a schedule

The routine runs hourly and checks our Slack feed for new PRs, we classify that as any PRs that were opened and not actioned upon in the last four hours. That keeps us working only from fresh PRs.

## PROMPT

You automate the Seer fix-reviewer verification flow in the <#sentry-slack-channel> 
Slack channel (channel_id ). 

This runs every 4 hours, 7 days a week, and unattended — execute autonomously, 
make reasonable choices, and never ask questions. 

Your Slack user_id is . The Sentry bot is . 
End with a short per-PR report.

Identifies a reviewer

First, Claude sends a pre-written Slack message to the Seer agent with a prompt asking who's best suited to review the PR. Seer looks at commit history in our GitHub repository and finds the person who has worked most closely with the code flagged in Seer's root cause analysis.

Checks that the PR is open

Before assigning a PR, we make sure it still exists. We check its status, and if it's already merged, closed, or otherwise off, we skip it silently.

Pings the reviewer

If the PR is valid, the routine tags the reviewer in the thread with the Seer-created PR and asks them to wrap it up by:

Merging or closing the PR
Leaving one line of feedback
Noting whether this was a good use of Seer

We also built the routine so it never double-posts a prompt, question, or DM. The goal is for the agent to streamline our work, not add noise to it.

To be clear, this wasn't a one-shot setup. We spent a couple of weeks iterating on it. For example, we needed to make sure that engineers weren't getting pinged on the weekend or that they weren't getting pinged right after assignment. These were things we only learned by trial and error, and we're still looking for ways to improve the overall flow. There isn't a one-size-fits-all-orgs solution here; the key is standing something up that feels right and then iterating out the wrinkles.

Early results

One caveat: we only rolled this workflow out in mid-July, so we'll need to revisit it in a few months to really judge how it's working. Early on, though, the signs are positive. A few of the numbers we're seeing:

About a 21% increase in the action rate on PRs
About a 13% increase in the 48-hour response rate on open PRs
About a 12.5% increase in close-without-merge PRs

Looking at these results, you might think an increase in close-without-merge isn't a great stat, so why share it? It could mean the proposed fixes aren't useful, or that they don't solve the root of the problem. So we did a little more digging. That wasn't the case.

The close-without-merge PRs followed a couple of common themes. They were either a duplicate fix already covered in a separate PR, or the reviewing engineer opted for a more comprehensive fix that went beyond the scope of the original issue. In both cases, the workflow is doing its job. Engineers are getting notified that fixes are ready and taking action on those PRs. That beats a pile of untouched PRs sitting there.

If there's one takeaway here, it's this: automated debugging is possible, and it's genuinely useful. The key to that is building a system that brings in the right people at the right time.

Seer is the engine that powers this whole workflow for us. We rely on Seer to help us:

Diagnose issues
Propose a fix
Alert our Slack channel when it creates a PR
Identify and inform the right engineer to keep in the loop

We add a bit of automation with Claude, but largely are leveraging Seer for as much as we can. It's also inspired us to build even more functionality into Seer to enable this loop. We're exploring ways to have Seer assign PRs to the most relevant user and notify them automatically.

Try it yourself

Best of all, everything we've described is available for you to try today, so now it's your turn. Here's the setup:

Seer agent in Slack
Seer autofix enabled on a project
Claude routines or Cursor automation
GitHub CLI

One quick note about Seer autofix. It will not create a PR for every issue automatically. Before creating a PR, Seer assesses the fixability and severity of the issue, details of that criteria can be found in our documentation.

New to Seer autofix? Try it free for 14 days. You won't be charged when the trial ends — you'll only pay if you decide to keep it. After that, it's $40 per active contributor, per month, for unlimited use.

Your OTel spans, our errors: A Sentry love story in one trace

Wed, 05 Aug 2026 09:00:00 GMT

You can already send OTel traces to Sentry. Point your OTLP exporter at Sentry's endpoint, set environment variables, and your spans show up in the trace explorer. Our OTLP setup guide and "You Don't Need to Pick One" walk you through that.

But those spans are islands. You get a trace waterfall in Sentry, sure. What you don't get is the thing that makes Sentry valuable:

Click an error => see the OTel trace that caused it
Click a span => see the Sentry errors that fired inside

That connection between your OTel performance data and your Sentry error data doesn't exist unless something on the SDK side actively wires them together.

That's what the OtlpIntegration for Python, Ruby, Node.js, Go, PHP, .NET, and Java does.

Trace connectedness: the problem the raw OTLP endpoint can't solve

When you use a standalone OTel SDK with Sentry's OTLP endpoint, two separate systems run in your process:

The OTel part manages traces and spans.
The Sentry SDK manages errors, logs, application metrics, session replay, and profiling.

They share a process but not a context. When the Sentry SDK captures an error, it doesn't know which OTel trace is active. When the OTel SDK exports a span, it doesn't know a Sentry error happened during that span.

The OtlpIntegration bridges that gap. It reads the active OTel trace context and stamps the trace_id and span_id onto every Sentry event. That's what makes an error show up inside its OTel trace waterfall, and what makes the trace waterfall show which spans had errors.

What the OtlpIntegration does under the hood

It does three things:

Configures an OTLP exporter pointed at Sentry's ingestion endpoint, derived from your DSN. Your OTel spans flow into Sentry over standard OTLP.
Reads the active OTel trace context and stamps it onto every Sentry event (errors, logs, application metrics, etc.) so they appear connected in the trace waterfall.
Optionally registers a SentryPropagator for compatibility with services using Sentry's native tracing. (Note: this auto-setup is being removed in the next major version across all SDKs, and propagation will be a documented opt-in instead.)

Why this replaced our previous approach

Our previous strategy, which we call POTel, deeply integrated the Sentry SDK with OpenTelemetry. That approach had its benefits: Sentry and OpenTelemetry spans could be interleaved within the same trace, context propagation was unified, and users could take advantage of OpenTelemetry's instrumentation ecosystem with minimal friction.

Our new approach makes a different trade-off. Rather than requiring every Sentry SDK to integrate deeply with OpenTelemetry, backend SDKs now work independently, with no mandatory OpenTelemetry dependency or coupling to OpenTelemetry's release cycle. In exchange, we give up in-process span interleaving, but gain a solution that is consistent, portable, and practical across all supported backend SDKs.

For users who need the tighter integration, Java continues to support the original POTel approach, where its mature OpenTelemetry ecosystem makes that model a good fit.

Two env vars and an init call

For Python, all you need is two environment variables for the exporter and two lines in your initialization code.


from sentry_sdk.integrations.otlp import OtlpIntegration

sentry_sdk.init(
    dsn="https://<key>@<org>.ingest.us.sentry.io/<project>",
    integrations=[OtlpIntegration()],
)

The integration picks up the OTLP exporter config from OTEL_EXPORTER_OTLP_TRACES_ENDPOINT and OTEL_EXPORTER_OTLP_TRACES_HEADERS, sets up a TracerProvider with a BatchSpanProcessor, and wires trace context onto Sentry events. If you already have your own TracerProvider, the integration detects it and skips auto-setup. Other SDKs follow the same pattern with language-appropriate idioms. See the OTLP integration docs.

And here's what you get in Sentry:

Where POTel still lives (and where it doesn't)

Java is the only SDK where POTel is the current long-term path. Java's OTel ecosystem is mature and stable. The deep integration gives real value there: Sentry scopes propagation, automatic breadcrumb capture, the works. The OTLP integration exists as an additional option, not a replacement.

JavaScript (Node.js) is in transition. Today, the full Node.js SDK still bundles OpenTelemetry with automatic instrumentation (POTel). We've also shipped a lightweight mode (imported from @sentry/node-core/light) that drops the OpenTelemetry dependencies entirely. You still get errors, logs, metrics, and manual spans; you just don't get automatic instrumentation. In v11, we take a similar lightweight approach. There is no OTel TracerProvider set up, but you do get automatic, Sentry-native auto-instrumentation.

Who is this for?

This is a great fit for teams that:

Are already invested in OTel for backend tracing. They have TracerProvider set up, auto-instrumentation running, maybe even an OTel Collector. They don't want to rip that out to adopt Sentry tracing.
Use (or evaluate) Sentry for errors. The value proposition: "keep your OTel traces, add Sentry for errors, and the integration connects them. Click an error, see the trace. Click a span, see the errors."
Run a polyglot backend. The integration works across multiple Sentry SDKs. An org with Python microservices talking to Go services talking to a .NET monolith can instrument each with OTel and see unified traces in Sentry.

Traces and logs yes, errors and metrics no

You get:

OTel spans in Sentry's trace waterfall, stitched with Sentry errors, logs, and other events on the same trace
Distributed tracing across services, whether they use Sentry native tracing or OTel
OTLP log ingestion (but see caveat below)

You don't get:

Errors via OTLP. The most common misconception. Errors still require a Sentry SDK. OTLP handles traces and logs, not exceptions. If a customer only wants to point an OTLP exporter at Sentry and skip the SDK, they get traces but no error tracking.
Interleaved Sentry and OTel spans in the same process. You choose one tracing system per service. Don't set traces_sample_rate on the Sentry SDK if you're using OTel tracing, because it produces duplicate spans.
OTLP logs connected to errors without OTLP traces. The log-to-error link depends on shared trace context. If you only need logs without tracing, Sentry's native logging is the better path.

Propagation is becoming opt-in

The automatic SentryPropagator setup is being removed across all SDKs (Python, Ruby, .NET, Java). OTel only allows one global propagator at a time, so silently registering one can conflict with whatever the user has already configured. Users who need sentry-trace header injection for mixed environments will set up a composite propagator themselves.

Check out Sentry for OpenTelemetry or the OTLP integration docs for setup details.

And that's pretty much all there is to know. Keep your OTel, add Sentry, and let one trace tell the whole story.

Session Replay for Unreal Engine: see the crash before the crash

Fri, 24 Jul 2026 09:00:00 GMT

You know the drill: a crash report lands in your queue with a pristine stack trace pointing at some innocent-looking function and absolutely no clue about what the player was actually doing. Were they mid-boss-fight? Alt-tabbing during a loading screen? Standing perfectly still in the tutorial? QA can't repro it, the player's bug report says "game crashed lol," and you're left staring at a callstack playing twenty questions with a core dump.

Stack traces tell you where the code died but not always why. Since games tend to be much less deterministic than typical desktop or mobile apps, the "why" often lives in the seconds before the crash.

That's exactly the gap Session Replay fills. With its new Session Replay support, the Sentry SDK for Unreal Engine can now continuously record the last several seconds of gameplay and attach that clip to the crash report. When the crash lands in Sentry, so does the footage, allowing you to watch what the player saw, right up to the moment things went sideways.

What you get with Session Replay

When a crash with a replay arrives, it shows up on the Replays page linked to the crash event as a playback with the actual rendered frames of your game and a scrubbable timeline of everything important that was going on along the way.

The panels next to the player are where the debugging happens. Alongside the footage and an AI replay summary, each replay gives you:

Tags & context - the answers you'd normally have to ask the player for: OS and version, release, crash type, region, etc.
Breadcrumbs - errors, gameplay events, and your own custom breadcrumbs on a timeline synced with the video.
Logs - the game's log output timestamped against the video.
Trace - the spans leading up to the crash, linked by a shared trace ID. If the crash involves your backend, the server-side spans of the same trace are accessible from here as well.

Looking at the example above, those things tell the full story: three seconds in, an ensure fires because a checkout HTTP request came back invalid; the player reaches level 2, picks the "Wrath" attack modifier, and at 00:22 - fatal crash in ASentryTowerTurret::Shoot. That's a reproduction script, handed to you by the crash itself.

In fact, you don't even have to leave the crash to start watching. The replay is embedded right on the crash event page, so triaging an issue can start with a quick glance at the last few seconds of gameplay. If that glance raises questions, the full replay page is one click away.

How it works

Earlier experiments with replay capturing in the Unreal SDK leaned on platform vendor features (e.g. GDK's game DVR on Xbox). That works, but every platform behaves differently and some can't ship at all.

For the new desktop and mobile implementation we went the other way and built the recording pipeline out of Unreal-native facilities so the same code runs everywhere the engine does. It has three main players:

The backbuffer capture hooks Slate's OnBackBufferReadyToPresent on the render thread, throttles to the configured capture framerate (default 30 FPS, if your game can render faster frames are sampled down), and copies each frame into a texture the encoder can consume. Backbuffers come in many formats (e.g. 10-bit, HDR) and Slate doesn't create them as shader resources, so the capture path does a hardware copy into a scratch texture and lets an engine pixel shader handle format conversion. If you're already rendering BGRA8, it degenerates into a straight GPU copy.

The video encoder runs on a dedicated thread and feeds captured frames to a hardware H.264 encoder via Unreal's AVCodecs plugin family (NVENC on NVIDIA, AMF on AMD, VideoToolbox on Apple). The right encoder is picked at runtime based on the player's GPU. Encoded output is grouped into short fragments at keyframe boundaries and muxed into fragmented MP4.

The replay recorder orchestrates the whole thing. It maintains a rolling ring buffer of completed fragments only ever keeping the configured replay window and periodically assembles them into a complete, playable MP4 on disk. Each snapshot is written to a temp file and atomically renamed, so there's never a torn, half-written video lying around.

When a crash happens, the Unreal SDK picks up the latest rolling clip along with the crash report, wraps it into an envelope, and handles the upload to Sentry.

If the player's machine has no compatible hardware encoder, the feature self-disables for the session and logs a warning, so crash reporting itself is never affected.

What does it cost you at runtime?

"Continuously encode video of my game" sounds like the kind of thing that eats a game's frame budget for breakfast. So we measured it.

We profiled our Unreal demo game with the engine's CSV profiler - once with replay off as a baseline and once with it on. We ran it at 4K fullscreen deliberately, as a bigger backbuffer means a bigger copy and encode cost, so 4K marks the worst case and the overhead at lower resolutions only goes down.

Metric	Baseline	Replay On	Δ	Δ %
Frame Time	5.56 ms	5.77 ms	+0.20 ms	+3.6%
Render Thread	5.56 ms	5.67 ms	+0.11 ms	+1.9%
Game Thread	1.72 ms	1.82 ms	+0.10 ms	+5.8%
GPU	4.96 ms	5.04 ms	+0.08 ms	+1.6%
RHI Thread	1.81 ms	1.82 ms	+0.01 ms	+0.5%

The bottom line: about 0.20 ms per frame at 4K. That's ~1.2% of a 16.7 ms frame budget at 60 FPS, or ~2.4% at 120 FPS. Most of it comes from the render-thread backbuffer hook while encoding and file rotation happen on background threads, so the game thread, RHI thread, and GPU barely notice.

Getting started

Session Replay ships with the Sentry Unreal SDK 1.16.0, so if you already have the plugin set up, it's one toggle away.

Enable the AVCodecsCore engine plugin plus the codec plugin for each GPU vendor you want to cover (NVCodecs, AMFCodecs on Windows and Linux, VTCodecs on Apple platforms). They all can live side by side since the right one is picked at runtime.
In Project Settings > Plugins > Sentry, expand "Session Replay" and toggle "Enable session replay (experimental)".
Rebuild the plugin. Whether replay is compiled in is decided at build time, so after toggling the setting, make sure you start clean by deleting your project's temporaries and rebuild.

That's it. Replay duration, capture framerate, bitrate, and fragment length are all tunable (see the Session Replay docs covering every knob, plus per-platform requirements).

One important caveat: currently there is no automatic masking. The recording captures your rendered frames as-is, so player names, chat, and anything else on screen ends up in the video. Make sure the content your game renders is safe to record and that your privacy policy accounts for it.

Help us shape this

Session Replay for Unreal Engine is an experimental feature, and a lot of what we build next depends on the feedback you give us.

So, try it in your project, watch a few crashes with footage attached, and let us know what's missing. Open an issue (or just react to an existing one) on GitHub or come chat on our Discord. Fewer "cannot reproduce" resolutions for everyone.

From 57 bugs to 1, thanks to Seer

Thu, 23 Jul 2026 09:00:00 GMT

Guest post by Dan Mindru. Dan is an indie maker, enterprise consultant, and co-host of the Morning Maker Show. He maintains several open source projects and is the founder of Crontap, Saventify, and about 10 other startups.

I was at the dentist the other day, getting ready for my appointment. The waiting room was pompously decorated. Each chair seemed to be from a different, expensive Danish designer. As I realize I'm about to get charged through the nose, I get a notification from my beloved Mail app.

** ding **

Screenshot of GitHub email notification

It's a new Pull Request on GitHub. This one is different though. I have no idea where it came from! As I scramble to figure out what automation triggered this, some intrusive thoughts start to take shape... Have I been hacked?!

I open the code tab to find it's a perfectly reasonable fix, including a unit test update and all. Not only that, it looks low risk and all checks are green too.

As the dentist calls my name for probably the third time, I panic and (against my better judgment)... I press "Squash and merge".

I put my phone back in my pocket and mumble to the dentist: "Sorry, I was in the zone...".

I was never going to fix that bug

You've probably shipped to production from the dentist a lot more than I have, but to me this felt like a big shift. It's not just that I merged some code. It was cheap code. Code that I didn't need to work for or prioritize.

So what happened? Where did that PR even come from? Hold on for a second.

First, we need to have an honest chat about bugs and prioritization. If you've ever worked on any production system, issues will pile up and you'll eventually end up having to triage bugs, usually asking these questions:

How many users are affected?
What's the impact?
How long will it take to fix?

Based on this, a stakeholder will assign a priority to the bug. Usually everything that's less than high goes into what they call "the backlog".

If you're new to this, "backlog" in enterprise is short for Bottomless Abyss of Casually Kept, Long-Overdue Grievances.

But how much business value does fixing that bug bring compared to <insert-feature-ceo-is-excited-about-here>? How much harm can that one bug really cause? After all, we had it for months.

Indeed, the fate of this bug was sealed the moment it was compared to a higher priority feature. It's not a problem of discipline or willpower, it's a simple problem of economics. The cost of fixing it can't be justified when compared to adding a feature that potentially brings heaps of new customers.

Fast forward a few years, and you end up with (you guessed it) 57 bugs in the backlog.

I'm excited to show you how we got it down to 1!

The economics of fixing bugs are changing

What I've described used to be the case for most companies. I don't think that's true anymore. Around Spring 2026, a number of things came together in AI that I believe completely changed the economics of fixing bugs:

model intelligence
larger context
better harnesses & tool calling
new abstractions (skills, hooks, sub/cloud agents, etc.)
longer running agents

All of this resulted in a leap that flipped the economics of fixing bugs from "not worth it" to "what the heck, let's take this one into the sprint too".

In the midst of all this, I was happy to have had Sentry running in all of our systems.

You see, all of the above is worthless if you don't have context. With enough context, most bug fixes become trivial for AI to both fix and verify.

And Sentry has the juiciest, most valuable context of them all: traces, device information, network, logs. Just to name a few. To my surprise, it even uses Session Replays as context?!

An issue in Sentry for a navigation error on hunted.space, with Seer Autofix open on the right showing an "Evidence" footer containing a Session Replay.

Pro tip: the more telemetry you send (traces, profiles, logs), the better every automated fix downstream gets. I highly encourage you to set up JavaScript logs in Sentry.

With this context a third of the job is done without even lifting a finger. Another third is implementing the fix. And the final third is verifying it.

In theory, if we could automate all three thirds, we'd be able to close most bugs in our sleep. And that is exactly what I want to talk about in this post. I believe most bugs can be solved automatically now.

If bugfixing were a stock, it'd slide down like Lehman Brothers in '08. Except this time, the crash is the good news.

Let me show you how to set this up.

How to fix your own bugs cheaply while you relax

To pick a correct setup, we need to first get into the mind of a bug. You need to "think like a bug", if you will.

Bugs have feelings too

Not all bugs are created equal. The nice ones have a cool hairstyle and sunglasses. The bad ones have a mohawk and a tattoo. In general, we can sort bugs into 3 categories:

Category	Isolated	Reproducible	Complexity	Fix?	Verification?
Friendly	Yes	Yes	Low	A few surgical lines of code	Unit test
Grumpy	Mostly	Mostly	Medium	Spans a few files and needs some digging	Unit + Integration tests + Visual regression tests + Smoke tests
Punk	No	Sometimes	High	Nobody knows; easier to rebuild the thing than reproduce	Unit + Integration + E2E, DB checks, Visual regression tests, Plus human smoke tests

Let's take a look at each of these in detail and see how each can be fixed in the cheapest way possible.

Friendly bugs

These bugs are the ones that are easy to fix. They are isolated, reproducible, can be easily validated/reviewed and aren't risky to merge.

Examples:

calling an API with invalid payload
a missing null check that throws when a field is empty
an off-by-one error that drops the last item in a list
a layout breaking on mobile

But don't be fooled! As innocent as they look, these can be super frustrating to users and can lead to a bunch of support tickets too.

I am happy to let you know that these bugs are solved.

You can automate them away with this simple setup:

[Pre-requisite] Add Sentry to your application to get the required context (Sentry platform setup docs)
Connect to your GitHub repo
Go to Seer settings and link your project to the corresponding repository(ies). This is what Seer reads for root cause analysis and code generation.
On the same settings page, also set the Automation step to Stop after PR drafted.

"Stop after PR drafted" is the most hands-off of the three automation levels. If you'd rather keep a human in the loop earlier, you can also stop after Root Cause (analysis only) or after Plan (suggested fix, no PR).

If you can't find Seer settings, make sure you have enabled "Generative AI Features" in your org's general settings.

And just like that, no more Friendly Bugs. How does this work in practice?

From my perspective, I just get PRs every few days. They usually contain fixes spanning a few lines of code. I see if all checks are green and hit the merge button. That even closes the issue in Sentry so if you're as lazy as I am, you'll love it!

A nice touch: Seer automatically parses your rules files (Cursor, Claude Code, etc.), so both the analysis and the handed-off fix follow the same conventions your own agents do.

From Sentry's perspective, it's a more involved process. An issue has to earn its automatic fix:

the issue has enough events registered that it's clearly not a fluke
the issue is recent (currently, within the last 14 days)
the issue has a sufficient fixability score: Sentry estimates how straightforward the issue is to resolve, and only confident ones proceed

In my experience, what this means is:

You don't get spammed with PRs.
When a PR comes in it's usually a slam dunk.

Just by enabling this, you've probably already fixed a massive chunk of your bugs. It's quite remarkable. Let's go deeper now!

Grumpy bugs

These bugs are harder to crack. They have more unknowns, and typically require deeper investigation. However, they are still mostly isolated and reproducible, only the fix spans multiple files now.

Examples:

a race condition between two API calls that only shows up on slow connections
state that goes stale after a websocket reconnect
an optimistic UI update that never rolls back when the request fails
a pagination bug that skips or duplicates items when data changes between pages

These are a lot harder to justify financially. Typically they'd be written off as "edge case" and deprioritized.

If you expect me to write "but Seer also fixes these" and move on to the next section, I won't. I can't lie to you, Seer alone cannot fix these.

Seer is a fantastic investigator, but it doesn't have a full-blown environment to apply & verify the fix. It can't spin up a dev server, can't poke at a database, can't press the button that triggers the bug 5 steps into the flow.

By now we should know: if the agent can't verify, the task is not done.

So for Grumpy bugs, we let Seer do what it does best (root cause analysis with all that juicy production context) and then hand off the actual fixing to an agent that does have an environment: a full-blown cloud coding agent.

You can currently select between:

agents, with more likely on the way. Let's pick Cursor for this example.

Here's the setup:

In Sentry, go to Settings → Integrations → "Cursor Agent", and click "Accept & Install".

Note: there's also a Cursor API integration. Make sure to pick the one that has the "Coding Agent" tag.

Head over to Cursor Account Settings and generate an API Key under API Keys in your profile.
Go back to Sentry and paste the API key.
Finally, go to Seer settings, select your project and set Handoff to Agent to "Cursor Cloud Agent" and Automation Steps to "Stop after PR drafted".

Seer Settings with a project that has Handoff to Agent and Automation Steps set to the described values

If you'd like more control over third-party Cloud Agents, you can keep Seer as the "Handoff Agent" and trigger the third-party Cloud Agent manually on a per-issue basis.

On any issue's Root Cause Analysis card, click the dropdown next to "Find Solution" and launch a Cursor Cloud Agent. Great for when you want to delegate one specific bug instead of automating everything.

What really happened at the dentist

Now you're finally ready for the big reveal. Why did I get that PR at the dentist?

Turns out, a colleague happened to enable the Cursor Agent in Seer settings a few days before. Sentry determined the bug was worth fixing, handed it off to Cursor, and after implementing and verifying the fix, it opened a PR (more on this handoff in a minute; it's the key to the next category of bugs too).

The confusing part was that there was no link back to Sentry, and I couldn't see the Cursor Agent chat either, hence my initial panic. Checking this on my small screen didn't help either, as I missed some of the PR metadata I'd usually look for on a larger screen.

GitHub Pull Request overview with the issue description summary and root cause

So, how does the handoff to the coding agent work?

Seer's Autofix flow has three steps:

Root Cause Analysis
Solution Identification
Code Generation

With a handoff configured, Seer still performs the root cause analysis and gathers that juicy production context (stack traces, breadcrumbs, traces etc.), but instead of generating code itself, step three goes to the Cursor Cloud Agent. The prompt will contain everything Seer found so far.

Cursor Cloud Agent Prompt containing root cause analysis

The agent then checks out your repo in a real environment where it can:

run your unit and integration tests
spin up a dev server and actually exercise the broken flow
use any MCP from the Cursor marketplace to go further: query a dev database, drive a browser, check CI, write and execute E2E tests, take screenshots etc.

In other words, it closes the loop. Investigate → fix → verify. That last third of the job, the expensive one that used to be handed over to a human, is now also automated.

With this in place, you're likely down to 80-90% of bugs being fixed. Now it's time for the boss level. Things won't be as smooth from here, let's take a look.

Punk bugs

These are the bugs that take a good look at your test suite and burst into laughter. They're not isolated, they're barely reproducible, and the root cause usually lives somewhere AI can't casually wander in, like production data or a third-party service.

Examples:

a crash caused by old production data: records created by a migration 5 years ago, in a shape your current code could never produce
a bug that only triggers for one customer because of their specific combination of feature flags, plan, and account age
behavior that depends on a third-party service doing something undocumented (an auth provider, a payment webhook arriving twice)
an issue that only shows up at production scale: a query that's fine with 10k rows and pathological with 50 million
something environmental: a corporate proxy, production config, a browser extension, a device you don't own

The missing piece is production. If you made it this far down the article, you're probably clever enough to know we should never, under any circumstances, give AI access to production.

The best way to fix these is to have the agent work with you. Typically, this will involve you cloning some records to dev, observing the agent and generally taking the time to understand what's going wrong.

The context is still just as valuable though, so how do we get it?

The setup for these bugs is:

Add the hosted Sentry MCP server to your favorite IDE or agentic CLI. In Cursor that's Settings → MCP → New MCP Server (or just edit mcp.json in most agentic coding tools):

{
  "mcpServers": {
    "sentry": {
      "url": "https://mcp.sentry.dev/mcp"
    }
  }
}

Log in to your Sentry org via OAuth. Click through and you're done.
Open the agent chat and start asking questions in plain English: "I would like to investigate the root cause of a production bug. Pull the events for SAVENTIFY-1R from Sentry and look at the breadcrumbs".

Using the Sentry MCP to investigate a Saventify bug in Cursor.

The MCP server gives your agent direct access to everything it needs to investigate and propose a fix, including Seer that can run a tool to root cause analyze right from the chat.

As the agent pulls the context, you contribute with historical data and business logic that's not obvious:

"Those accounts were migrated from the old system in 2021 and have a different config"
"We changed payment providers that quarter"
"That customer is behind a corporate proxy"

Each of these one-liners will dramatically increase your chances of finding the correct root cause. Once you do, the fix can be fully automated and sent off to a Cloud Agent to fix if it can also be reproduced on a dev environment. Otherwise, you'll need to manually verify the fix.

Because of this, these bugs will always be expensive to fix. In some cases, they can only be fixed by a person that happens to have specific historical/business context. Realistically, no amount of AI can get around it, and I suppose that's why building software can be a blessing and a curse at the same time.

Reducing investigation and verification time is the best we can hope for, and this workflow does exactly that.

What was that one bug you couldn't fix?

I know this is what you've all been waiting for.

"If you're so clever at explaining this bullet proof setup, Dan, then how come you didn't fix all your bugs?"

This boils down to cost and a high risk / low reward combination. Just to reproduce, this bug requires:

A production MSAL config
A Microsoft failed request + redirect and
Timing to be just right in order to reproduce.

In short, users experience this bug as data loss, which is catastrophic in my eyes. When they perform certain create/update actions and their auth token expires, MSAL sometimes fails to perform a silent refresh token call, and the application will go through a series of redirects that drops the redirect URL together with the data they entered.

This has been so hard to fix that we've contemplated switching auth providers. A few times now. It might be cheaper and more reliable at this point.

In the meantime, we had to take a step back and think outside of the box. After many failed attempts at a fix, we ended up implementing save/restore on every keystroke, so at least users can pick up where they left off next time they access that URL.

Wrapping things up

It's hard to say what makes people emotionally attached to a product. It's usually a mix of branding, design, features, performance, customer support and ultimately: value for money.

However, it's a lot easier to figure out when people start to hate a product: If you introduce enough paper cuts, they will start to think they can't trust your app anymore. Not addressing bugs is risky business. Once a certain threshold is crossed, there's not much you can do to turn it around. Even if the mistake is on their side, they'll still attribute it to your product.

This will leave users more and more frustrated, and ultimately make them recommend against your product. That's the absolute worst case scenario.

Luckily, most bugs are not like this.

Thanks to recent AI advancements, Sentry and Seer, most bugs can now be fixed at a fraction of the cost. I strongly encourage you to try it, you won't look back!

.NET support for Godot is now generally available

Wed, 22 Jul 2026 09:00:00 GMT

We recently released version 2.0.0 of Sentry's Godot Engine SDK, bringing C#/.NET support and application metrics to general availability. That means you can now capture errors from your managed C# code and track custom metrics across your development and retail builds.

C#/.NET support

Godot supports two fairly distinct worlds of scripting: GDScript and C#. During the 1.x releases, we instrumented the SDK to capture issues from GDScript, the engine itself, and the native C/C++ code, and expanded support to all officially supported platforms. With the 2.0.0 release, we're introducing first-class error reporting for .NET in Godot Engine.

Errors from your managed code now appear on the same trace alongside GDScript and engine issues, and scope elements like tags, breadcrumbs, and user context are present where they're currently synchronized.

So, let's see how this works in practice. Here's a short version of C# code that throws at runtime in our Godot game:

private List? TryFetchUpgradesFromServer()
{
    var fetchTransaction = SentrySdk.StartTransaction("fetch_upgrades", "http.client");
    return ParseUpgradeData(FetchUpgradeDataFromServer(fetchTransaction), fetchTransaction);
}

private List? ParseUpgradeData(string responseContent, ITransactionTracer transaction)
{
    // ...

    // Parsing the server response throws JsonException
    var serverResponse = JsonSerializer.Deserialize(responseContent);
    var upgradePaths = new List(serverResponse!.upgrades.Length);

    // ...
}

The SDK captures the error at runtime and sends an envelope to your Sentry project. This is how the issue looks in Sentry:

Sentry has integrations for most popular SCMs, like GitHub, and can fetch the source code context around each frame right from your repository.

Metrics

To better understand performance across different hardware configurations, you can send metrics to Sentry so you can track performance over time and slice it by custom attributes. In this example, we measure the actual time between frames instead of relying on the engine's delta time, since delta time is typically clamped and smoothed. We also attach CPU and GPU attributes, making it easy to slice the data by hardware configuration. You can add other attributes to narrow the data down even further, such as the game level where the metric was recorded.

Here we're looking at the p95 frame time to spot configurations where the game consistently struggles to run smoothly. This makes it easier to identify hardware-specific performance issues, or even level-specific bottlenecks, and focus your optimization efforts where they'll have the biggest impact.

extends Node
## Samples frame time and sends it to Sentry as metrics.

const FRAME_SAMPLE_INTERVAL_MS := 100.0

var _time_since_sample: float = 0.0
var _last_frame_usec: int = Time.get_ticks_usec()

func _process(_delta: float) -> void:
    var now := Time.get_ticks_usec()
    var frame_ms := (now - _last_frame_usec) / 1000.0
    _last_frame_usec = now
    _time_since_sample += frame_ms

    # Sample at a fixed interval to avoid producing too many metrics.
    if _time_since_sample >= FRAME_SAMPLE_INTERVAL_MS:
        _time_since_sample = 0.0
        var attributes := {
            "gpu.name": RenderingServer.get_video_adapter_name(),
            "cpu.name": OS.get_processor_name(),
            "cpu.cores": OS.get_processor_count(),
        }
        SentrySDK.metrics.distribution("perf.frame_time", frame_ms,
                SentryUnit.millisecond, attributes)

For another example, let's track how long runs take and what experience level players reach on average in a roguelite/survivors-style game. game.run.time records the total time it took to complete a single run, while game.run.xp_level records the experience level reached during that run.

This example shows that metrics can be used to track more than just performance: they're also useful for gameplay events. Data like this can help you balance gameplay variables and create a better experience for your players.

extends Node
## Sends gameplay metrics to Sentry by listening for game events
## on the EventBus.

func _ready() -> void:
    EventBus.connect("EnemyDestroyed", _on_enemy_destroyed)
    EventBus.connect("RunEnded", _on_run_ended)

func _on_enemy_destroyed(_score_value: int) -> void:
    SentrySDK.metrics.count("game.enemies_killed", 1)

func _on_run_ended(xp_level: int, time: float) -> void:
    SentrySDK.metrics.distribution("game.run.xp_level", xp_level)
    SentrySDK.metrics.distribution("game.run.time", time, SentryUnit.second)

Try it out

Give it a try! We want to hear your feedback as we continue to improve the SDK. To get started, download Sentry from the Godot Asset Store, or directly from GitHub. Extract the archive into your project, set your DSN in the project settings under Sentry > Options, and let the errors come through with full context. For more details, check out the dedicated C#/.NET guide. Happy debugging!

How to structure a log

Tue, 21 Jul 2026 09:00:00 GMT

You've decided to step up your logging game and start sending more valuable, structured logs that you can query, aggregate, and use for debugging in production. Go, you!

Now, uh, how do you actually write them?

We're not going to spend much time on what you should log. We've covered that already, a few times before.

TL;DR: collect useful debugging context as code executes, then emit wide-event logs at meaningful milestones. Always emit a final outcome event on both success and failure paths.

What we will be covering is how to actually write those logs, answering questions like:

What shape should they actually be in?
How do we make them useful for querying and filtering?
How do we know the logs we write will be useful for debugging and understanding what happened?

What makes a log structured is not just pairing messages with arbitrary JSON objects.

Instead, we treat logs like real application data that we need to be able to search, filter, and aggregate to understand broad trends and debug specific incidents.

How we choose to actually write those logs will greatly impact how useful they are for debugging and understanding what happened.

Here is my very opinionated guide (as someone who spends time with Sentry logs users and helps them get more from their logging) to one way to write structured logs.

The shape of a structured log

The exact convention you decide to use matters less than whether it is predictable and applied consistently. Once you define a pattern and stick to it, you should be able to locate and understand any event in your system based on its log message and attributes.

The convention I use in my projects looks like this:

logger.warn('payment.capture', {
  'payment.id': payment.id,
  'payment.amount_cents': payment.amountCents,
  'payment.currency': payment.currency,
  'payment.result': 'failed',
  'payment.failure.reason_code': reasonCode,
});

A few patterns you'll notice in the example above, and I'll explain in more detail below:

Event names use a predictable pattern of domain.action.
snake_case segments, regardless of the programming language or framework you're using. One casing convention across services just makes querying later so much easier.
Flattened attribute objects using dot notation, not nested objects.
Predictable result attributes with low-cardinality values like succeeded, failed, retried, canceled, or completed for visualizing and grouping.
An expected or recoverable failure uses a warning log level.
Attributes should only contain primitive values or arrays of primitive values. No objects, including shallow objects, or arrays of objects.

Enforce log patterns with ESLint

I use a personal ESLint plugin for this to help enforce these patterns consistently across my TypeScript projects.

This is not an official Sentry plugin; these are just my opinionated guidelines. It is a logging-library-agnostic way to loosely enforce the shape of your logs. This does not go as far as, for example, validating zod schemas or similar.

If you want to follow along with my patterns, use the prompts below to install and configure my rules for your project. If you want to do something a little different, I highly recommend creating your own ESLint plugin or equivalent linting/tooling for your language to enforce your own patterns. Your agent/assistant can help you create whatever you need. Try running this prompt to customize your own rules for whichever language or framework you're using.

To install my ESLint plugin, give this prompt to your AI assistant:

Use stable event names

Let's start with what a bad log might look like:

console.log(`${user.name} logged in`, {
  userUuid: user.uuid,
  userName: user.name,
});

Technically, this is structured; it has a message and a data object. But the message is not stable. Every successful login creates a different log event for each user name, which makes the logs harder to query, group, and alert on.

A useful structured log needs a predictable event name. Dynamic data belongs in attributes, not in the message.

A better log message with a stable and predictable event name might look like this:

logger.info('auth.login', {
  'auth.result': 'succeeded',
  'user.uuid': user.uuid,
  'user.plan.tier': user.plan.tier,
});

This still communicates the event easily to humans and is easy to remember and query. Avoid logging usernames, and email addresses. Depending on your data policy you may or may not be able to include an identifier like a UUID.

For most application events, I like to segment the event name into two parts: the domain and the action.

domain.action

For example: "auth.login", "payment.capture", "webhook.delivery", or "cart.checkout".

The "domain" is fairly arbitrary, but I think of it as the closest context object you would want associated with it. As you collect context through your application, there are natural boundaries where you typically scope attributes.

When the user signs in, you might add auth.* attributes to the context. On a cart page, you might add cart.* attributes.

At checkout, the log event itself can describe the operation that finally happened, like cart.checkout with event-specific attributes. The event attributes might be the result of the checkout, as well as all of the context leading up to it, creating a debugging paper trail.

To enforce that convention with ESLint, configure the event-name rules like this:

Use scoped attribute keys

Event names describe what happened: payment.capture, auth.login, cart.checkout.

Attribute keys describe the facts you want to query about that event: payment.result, payment.amount_cents, auth.org_id, retry.attempt.

Use the same scoped dot-notation style for attributes, but think of attribute keys differently than event names. Event names are actions. Attribute keys are dimensions.

Think of each scoped key as a future question you are making cheap to answer:

payment.result              -> Did it succeed or fail?
payment.failure.reason_code -> Why did it fail?
payment.amount_cents        -> How much money was involved?
user.id                     -> Which customer was affected?
retry.attempt               -> Was this an early failure or repeated failure?

If a field might become a filter, grouping, dashboard dimension, alert condition, or incident-debugging clue, it deserves a stable scoped key.

A nested object preserves how your application stores data. A flat log event exposes the small set of fields you expect to query, group, alert on, and trust later.

Dot notation gives you some of the organization of nested data while keeping each field directly addressable. payment.failure.reason_code still feels organized like JSON, but as a string key, the value is immediately accessible without further parsing.

Scoped keys also help enforce safer logging practices. By manually defining the keys we want to log, we can ensure that we are only logging the data we intend to log, and not any other data that may be present in an arbitrary object.

Event scoped attributes

Once you have a naming convention for attributes, the next question is where those attributes should be attached.

Throughout the application, you should be adding context to your logs at natural boundaries that create a useful timeline of application state. I mentioned before adding auth.* attributes when the user was authenticated.

Different logging libraries handle context differently. For Sentry JavaScript SDK 10.32 or newer, use an isolation scope for request-specific context. Scope attributes must be strings, numbers, or booleans.

Sentry.getIsolationScope().setAttributes({
  'auth.org_id': user.orgId,
  'auth.user_tier': user.tier,
});

Every log emitted while that isolation scope is active receives the same auth.* attributes. Add only deliberate, policy-approved values: shared context is propagated broadly and is not a safeguard against sensitive-data collection.

On the log itself, we finally log attributes that detail the "action" that happened, along with any other useful information we can capture that may be useful for debugging. This typically includes a result for the action, and any application state that led up to it.

logger.info('cart.checkout', {
  'checkout.result': 'failed',
  'checkout.failure.reason_code': reasonCode,
  'cart.coupon_code': couponCode,
  'cart.total_cents': cart.totalAmount,
  'cart.total_items': cart.totalItems,
  'cart.item_ids': cart.itemIds, // scalar array of id strings
});

To enforce scoped attribute keys with ESLint, configure the attribute-key rule like this:

Keep event attributes inline

Spreads and helpers can make logs more consistent, but they usually belong at the context boundary, not inside every event log.

Shared contextual attributes like "auth.org_id", "auth.user_tier", or "flags.name" are often useful on many logs. Rather than spreading them into every event log, set them through your logger's context mechanism. For Sentry, use the isolation-scope pattern above. This keeps event attributes explicit, but every shared value still needs privacy and retention review before it is propagated.

Most attributes should describe the event itself and use its event namespace. Add a small number of surrounding contextual namespaces only when they materially help explain, filter, or investigate the event.

Keeping attributes inline makes it easier to review the log event where it happened, helps prevent unknown attributes from sneaking in, and ensures the log event is self-contained and easy to understand.

logger.warn('payment.capture', {
  'payment.id': payment.id,
  'payment.amount_cents': payment.amountCents,
  'payment.currency': payment.currency,
  'payment.result': 'failed',
  'payment.failure.reason_code': reasonCode,
});

Avoid this:

const paymentAttributes = getPaymentLogAttributes(payment);

logger.warn('payment.capture', {
  ...paymentAttributes,
  'payment.result': 'failed',
  'payment.failure.reason_code': reasonCode,
});

I keep this rule to help enforce consistency, but there isn't necessarily anything inherently wrong with using shared attributes or helpers to attach attributes to logs. You just need to remain consistent and be mindful about what you're logging. If you were using a schema validation tool, this would be less of a concern.

To enforce explicit attributes with ESLint, configure the inline-attributes rule like this:

Use primitive attribute values

Structured logs are most useful when attributes are easy to query, filter, group, and aggregate. That starts with formatting values in ways your logging backend can index and search predictably.

Along with a flat attribute key structure, I prefer to limit attribute values to primitives: strings, numbers, booleans, and arrays of those primitives.

The plugin can always reject values that are visibly non-primitive in the source, such as inline object literals and arrays of objects. Its default, non-type-aware behavior allows expressions whose runtime type is unknown, including identifiers and member expressions. Turning on disallowUnknownAttributeValues rejects those unknown expressions too, so use that option only if your project intentionally accepts the resulting false positives for ordinary dynamic values.

Logging raw objects is tempting when debugging because they preserve the full detail, but they usually add noise and cost without much query value. Nested objects vary wildly across code paths. Arrays of objects are even worse: they can explode the size of a log line while still being awkward to search.

Avoid this:

logger.warn('webhook.delivery', {
  webhook: webhook,
  response: response,
  error: error,
});

Prefer this:

logger.warn('webhook.delivery', {
  'webhook.id': webhook.id,
  'webhook.destination.host': webhook.url.hostname,
  'webhook.result': 'failed',
  'http.status_code': response.status,
  'retry.attempt': attempt,
  'error.name': error.name,
  'error.code': error.code,
});

That gives you fields you can actually query:

message = "webhook.delivery"
webhook.result = "failed"
http.status_code >= 500
retry.attempt > 2

When dealing with numeric values, it's a good idea to include the unit in the attribute name. size is vague. size_bytes is useful. amount is vague. amount_cents is useful.

A lot of structured logging examples out there will show timing data on the log event. If you are using a tracing provider, like Sentry, you should avoid manually timing operations in the log and implement custom spans instead. Tracing is the proper domain for timing operations. Because in Sentry, logs are trace-connected, you can easily correlate your logs with the spans they are associated with.

A few value guidelines:

Use strings, numbers, booleans, and arrays of those values.
Flatten objects into the few fields you will query.
Include units in numeric attribute names.
Avoid logging duration or timing fields; put those on spans.
Avoid logging full request, response, user, payment, or error objects.
Be especially careful with arrays. Arrays of strings are often fine; arrays of objects usually are not.

To enforce primitive values with ESLint, configure the primitive-attributes rule like this:

Keeping consistent with a linter

Once you find a pattern, enforce it with a linter. Not only will this help you remain consistent so your logs remain useful, it also makes your AI agents smarter. You can use /goal with your linter as the validation step to help automate writing and migrating logs.

Start with warnings while you adopt the pattern. Turn them into errors when your team is ready to enforce it in CI.

If you are using different languages for your frontend and backend, make sure you enforce the same pattern on both sides. That's another situation where I would ask AI to port my ESLint rules to Flake8 for python or other linters for other languages.

Linters can catch the shape of a log, but can't tell whether payment.result should really be checkout.result, or whether the event is missing the one field you always need during an incident.

For that, we can use a prompt with our AI agents to review and audit the logs for us, with our rules and guidelines in mind. This is again where we can use the linter with the /goal command to get even better results.

To review your logs with these rules, use this prompt:

A good log answers the next question

The point is not that every codebase needs exactly the same log schema. The point is that every codebase needs a shared idea of what a good log looks like.

Start with a boring convention: stable event names, scoped keys, event attributes written with intent, and primitive values your backend can search. Then enforce the parts a linter can understand, and review the parts that need domain judgment.

Good logs are not just breadcrumbs for the person who wrote the code. They are small, consistent records that help the next person answer: what happened, where did it happen, who or what was affected, and what should we look at next?

MongoDB Query Tracing in .NET with Sentry + OTLP

Mon, 20 Jul 2026 09:00:00 GMT

If your .NET app talks to MongoDB, you almost certainly want to be able to measure DB performance so that you can effectively debug any performance issues you might run into.

For that, you need to know which database command was running, how long it took, and whether this was a one-off blip or part of a broader pattern. Ideally, you also want to pivot from that trace to related errors and replays without stitching the story together by hand.

This post shows how to do exactly that using:

MongoDB's built-in OpenTelemetry instrumentation
Sentry's OTLP ingestion support in the .NET SDK
A small sample app that demonstrates the end-to-end flow

Once we're done, you'll be able to see your MongoDB spans and query data in Sentry and drill into these:

Why this approach

There were basically two ways we could have solved MongoDB instrumentation for Sentry users.

One option was to build and maintain a dedicated Sentry.MongoDB integration with its own ActivityListener and custom mapping logic.

That would work, but it also means more custom code to maintain, more translation between telemetry models, and one more special-case integration to explain.

The other option, and the one we chose, was to lean into OpenTelemetry and send spans to Sentry over OTLP. MongoDB already emits OpenTelemetry-compatible Activity data, and Sentry now accepts OTLP traces directly. So instead of building a bespoke bridge for each library, we can use the existing OpenTelemetry pipeline.

That is exactly why Sentry.OpenTelemetry.Exporter exists in sentry-dotnet: it wires OpenTelemetry exporting to Sentry's OTLP endpoint while keeping Sentry-specific context propagation in place.

Quick refresher: MongoDB + Activity in .NET

In .NET, OpenTelemetry tracing is built on System.Diagnostics.Activity.

Instrumented libraries create activities when work starts and stops.
OpenTelemetry SDK components listen, process, and export those activities.

As of recent MongoDB driver releases, MongoDB operations can emit this telemetry out of the box when instrumentation is enabled. That means queries, commands, and transaction-related operations can flow through your existing OpenTelemetry setup without you writing your own listener.

Prerequisites

At a high level, you need:

A .NET app using MongoDB.Driver with OpenTelemetry instrumentation support
OpenTelemetry SDK packages for tracing
Sentry.OpenTelemetry.Exporter in your app
A Sentry DSN

If you are following along with our sample from sentry-dotnet, I would just use the package versions defined there since they are already validated together.

Helpful references:

Wiring it up

The setup itself is pretty straightforward:

Initialize Sentry as usual for errors.
Enable OTLP mode so Sentry's built-in tracing instrumentation does not duplicate spans.
Configure OpenTelemetry tracing.
Add MongoDB instrumentation.
Export traces to Sentry using AddSentryOtlp(...).

A simplified shape looks like this:

SentrySdk.Init(options =>
{
    options.Dsn = dsn;
    options.UseOtlp(); // <-- Configure Sentry to use OpenTelemetry trace information
});

using var tracerProvider = Sdk.CreateTracerProviderBuilder()
   .AddSource(MongoTelemetry.ActivitySourceName) // <-- Subscribe to the MongoDB driver's built-in instrumentation
   .AddSentryOtlp(builder.Configuration["SENTRY_DSN"]!)
   .Build();

The key idea is simple: OpenTelemetry is responsible for producing and exporting spans, while Sentry remains responsible for crash reporting and end-to-end observability correlation and UI exploration.

Note: Without UseOtlp(), you can end up with duplicate spans if both OpenTelemetry and Sentry's built-in tracing hooks try to generate overlapping telemetry.

Capturing useful MongoDB query data

Getting spans is table stakes. The interesting bit is the context on those spans.

For MongoDB instrumentation, that includes command/query details so you can determine:

Which collection was involved?
Which operation type is slow?
Is this a repeated query pattern or a one-off spike?

The sample configures MongoDB and OpenTelemetry in a way that emits query command context and makes it visible in Sentry trace details and in the Queries experience.

What about PII in query data?

Query payloads can include user identifiers, emails, tokens, and other sensitive fields, which you may not be comfortable (or legally allowed) to store in Sentry.

When Sentry receives your MongoDB spans via OTLP, Relay derives a parameterized copy of the query, normalizes DB attributes and scrubs all the query values (replacing them with ?). That parameterized string is what is used to group and display queries in the Queries module.

However, Relay never removes or overwrites the original db.query.text. So the raw command, with real values like { "name": "Alice Smith" }, is retained verbatim on the stored span and shows in the span/exemplar detail view. So values are safe in the aggregate Queries view, but the raw PII is still stored and viewable per-span.

There are three different options for scrubbing this data:

Don't capture query text at all

This is the simplest and most reliable. Although it means you miss out on capturing some potentially very useful context.

Redact client-side via an OTEL span processor

The OTEL SDK for .NET allows you to register a class that derives from BaseProcessor which can be used to redact PII via an Activity.OnEnd hook. This is the technique we demonstrate in Sentry's MongoDB sample:

internal sealed partial class RedactSensitiveMongoData : BaseProcessor
{
    [GeneratedRegex("(\"contributor\"\\s*:\\s*)\"[^\"]*\"")]
    private static partial Regex SensitiveField();

    public override void OnEnd(Activity activity)
    {
        if (activity.GetTagItem("db.query.text") is string queryText)
        {
            activity.SetTag("db.query.text", SensitiveField()
                .Replace(queryText, "$1\"[Filtered]\""));
        }
    }
}

The scrubber above replaces any contributor field values with the text [Filtered] so that what is sent and stored in Sentry is the redacted version that doesn't contain any PII:

Server-side advanced data scrubbing

Advanced Data Scrubbing rules can target db.query.text.

The default rules only catch known-sensitive patterns (passwords, tokens, card numbers): they won't parameterize arbitrary field values, so for general PII you'd add an explicit rule/selector.

Correlating traces with Sentry errors and replays

One important detail in the OTLP integration is propagation context bridging.

When traces are produced by OpenTelemetry Activity, Sentry still needs to inject and read the right trace headers (sentry-trace and baggage) so issues, transactions, and downstream services line up correctly.

That support is built into the exporter integration, so you get correlation across tracing and errors without extra wiring in your application code.

In practice, that means:

You can jump from a slow MongoDB span to related errors or logs in the same trace.
You keep consistent distributed tracing context across service boundaries.

Viewing the data in Sentry

After running the sample and generating MongoDB activity, you can explore the data in a few places:

Explore -> Traces for end-to-end transaction timelines
Span samples to inspect individual MongoDB operations
Trace samples to view a waterfall showing how spans sit in the request lifecycle
Queries for searching and grouping span-level behavior

This is where the OTLP route really pays off. You are not looking at a custom side-channel integration; you are looking at first-class trace data that sits naturally with the rest of your Sentry observability workflow.

Closing thoughts

MongoDB already emits the right signals. OpenTelemetry already knows how to process them, and now Sentry ingests those traces natively via OTLP.

Instead of maintaining another bespoke SDK integration, we can use open standards, keep the setup simple, and still preserve Sentry's correlation and data-safety story.

To learn more:

Try out the MongoDB sample in the repo
Check out the OTLP integration docs

As usual, questions, feedback, or ideas for where we should take this next are all very welcome, so feel free to fire up a discussion at sentry-dotnet discussions.

Your agent should understand what you see

Thu, 16 Jul 2026 09:00:00 GMT

Sentry's Seer Agent lets you ask any questions about your data in Sentry, dive deep into that data, and fix issues faster.

One of its particularly cool abilities is letting you ask questions directly about what you're looking at in Sentry. Questions like "What's causing that latency spike?" or "What is the customer and region breakdown for this error?"

To answer these kinds of questions, the agent must see and understand what you are seeing inside Sentry at that moment. Getting that context right turns out to matter a lot: not just for answer quality, but for cost, conversation length, and the range of things the agent can eventually do on your behalf.

The straightforward approach: ASCII snapshots

Until recently, Seer understood the current page by taking what's essentially a screenshot rendered in text by scraping the DOM elements. It captures a character-by-character ASCII grid of everything visible on screen. It's crude, but it works. The agent can look at that grid and infer what's on the page, the same way a person could squint at a pixelated image and recognize rough shapes.

But this approach has three compounding problems.

Token cost. The ASCII grid is large. A single dashboard or issue feed page can consume thousands of tokens on average and p95 measurements for some pages reached 50k tokens or more. Every conversation includes at least one page snapshot, and more if the user switches views mid-chat. This cost scales with how much is on screen, not how much is actually useful to the agent.
Context rot. We mainly rely on Claude Sonnet or similar models as they strike a good balance between capability and cost. They have 200k token context length by default and this is shared across the system prompt, page context, conversation history, and tool call results. As it fills up, model performance degrades: earlier turns get pushed out, the agent loses track of what was asked, and responses become less coherent.
No path to richer interactions. An ASCII grid describes what's visible but can't express what's possible. There's no structure to attach hints like "you can click 'Edit' to change this widget," no way to flag which elements are interactive, and no foundation for future agentic actions where the agent could directly manipulate the page on your behalf.

Here's what it looked like before (note: data swapped out with dummy placeholders, but you'll get it, it was a big wall of everything, all at once):

The new approach: pages that describe themselves

Instead of ASCII screenshots, we have shifted to a structured context system that allows each page to effectively describe itself to the agent. The core shift is in who decides what the agent sees. Each UI component knows what it is, what state it's in, and what's worth telling the agent, and it contributes that information directly.

A few principles guide the design:

Semantic, not visual. The agent receives meaning, "dashboard in edit mode, 8 widgets filtered to production," rather than characters at grid coordinates. This is cheaper to send and easier to reason over.
Composable and compact. Each component contributes its own facts bottom-up: titles, modes, filters, key values. Decoration is omitted. New pages plug in without touching anything central.
Enables more interactions. The same channel that describes the page can carry hints about what's interactive and, eventually, instructions flowing the other way, letting Seer act on the page rather than just read it.

Now it looks more like this:

Under the hood, a React context provider at the root maintains a flat registry of nodes. Components opt in by wrapping themselves with a higher-order component. On mount, the wrapper registers a node and reads the nearest parent node from context to establish the hierarchy. The nesting comes for free from React's component tree: a widget rendered inside a dashboard automatically becomes a child node, no manual wiring needed. Each component then uses a hook to push its own data like title, mode, active filters, key values into its node. When the agent sends a message, the flat registry is assembled into a nested tree, serialized to JSON, and converted to markdown on the backend before it enters the system prompt. Components that haven't opted in yet fall back to the ASCII snapshot.

With the old approach, we sent everything visible, whether it's relevant or not, in a format not suited for LLMs. With the new approach, we only send useful information in a structured way that can be used to trigger targeted tool calls. The page describes itself concisely; when the agent needs more like the full rows of a table, details of a specific widget or raw data behind a chart, it fetches that on demand instead of paying for the full page context upfront.

What this looks like in practice

More context left for the actual conversation

Structured context is now live across many of Sentry's most visited pages and the token impact, measured on those pages, is significant.

Before the change, page context consumed between 85-93% of the system prompt on average. With semantic context, that share drops to 50-80% across covered pages, and average token counts fall by a large amount depending on the page. On dashboards, tokens dropped from ~5,500 to ~1,300 on average for the page context section. On the issue detail pages, which is the most visited page, the reduction is even sharper: from ~2,100 tokens down to ~300. Keeping page context size as a smaller part of the prompt means the agent can have longer conversations without running into context compaction or context rot issues.

Same performance, less cost

Importantly, the efficiency gains don't come at the cost of quality. Across over 14,000 runs with semantic context, we measured tool calls used per conversation and satisfaction rates measured after each conversation by using an LLM as a judge. Both satisfaction rates and average tool calls per conversation are on par with runs that rely on the prior approach. The agent makes roughly the same number of tool calls to fetch data and arrives at that point having consumed far fewer tokens to understand the page.

Where we are and what's coming

The pattern is now live across 24 of Sentry's most visited pages, including Dashboards, Issues, Explore, Traces, Logs, Replays, Performance, and more. Each page was a self-contained addition with no central changes required, which is exactly how the composable architecture was meant to pay off.

The first agent action built on top of this infrastructure is also ready: Seer can now create and update dashboards on your behalf. You can describe what you want to see (e.g. "a dashboard showing p95 latency by endpoint over the last 7 days alongside error rate") and the agent produces a fully configured dashboard with the right layout, queries, and widget types. Other teams are working on providing the agent semantic context and exploring options to have the agent interact with their page and take actions in the UI; watch for more built on this within Sentry in the months ahead!

Thanks to Jeremy Stanley and Jonas Badalic for guiding and helping throughout this effort.

When and what should I be logging?

Thu, 09 Jul 2026 09:00:00 GMT

This is a follow-up to Sergiy's post Errors, traces, logs, metrics: when to reach for what.

Modern observability platforms, like Sentry, give developers a lot of choice. For a given problem, should you use traces, profiles, metrics, logs?

If you take away one thing from this post, I hope it's this: when in doubt, start by adding a few targeted log lines.

Logs are straightforward to add to your application and they're a fast way to start collecting real information about how your software is running in production. When writing a new feature, I try to add enough logs that it's debuggable without a deployment.

It's okay for logs to be temporary instrumentation. Add them when investigating a problem or validating a feature, remove them when they're no longer useful.

Here are some best practices for using logs to make your application easier to debug and reason about.

Great things to consider logging

Important runtime decisions made by your application

Different users often see different flows. When you're debugging unexpected behavior, you want to know all the different decisions that determined how a request was served.

Some examples:

A user has a feature flag enabled that exposes an experimental version of a page.
Mobile users are redirected to a different experience.
Paid and free users receive different functionality.

When your application chooses between multiple code paths, consider logging both why the decision was made and what behavior resulted:

// Runtime decision: this user has a feature flag enabled
// that exposes an experimental version of the feed.
Sentry.logger.info("Check Feature Flags", {
  feature_flag: "fiesta_mode",
  feed_experience: "party mode",
  "user.id": user_uuid
});

These logs make it easier to understand why two users may have experienced the application differently and to reproduce bugs that only affect specific cohorts.

Whether a feature or algorithm is behaving as expected

Logs are useful when a feature performs multiple steps. By recording intermediate outcomes, you can understand where a process is breaking down and why.

Here's a real-world example. My site, allaboard.dev, allows users to import a climbing log-book from an external service. Logging the outcome of the import process helps me verify that the source data is being parsed correctly and identify where and if it fails.

// Stage 1 outcome: the export was authenticated and parsed.
// Record how much work we're about to do — if a user reports
// a bad import, the first question is "how many entries did
// we even receive?"
Sentry.logger.info("Third-party import started", {
  "import.source": "aurora",
  "import.entries_received": body.ascents.length,
});

// Algorithm runs here, populating skipDetails.

// Final stage outcome: a flat, queryable breakdown of how the
// run resolved. Each skip reason is its own scalar field so you
// can chart, say, a spike in `import.skipped.unknown_grade`
// (a Font→V-scale conversion gap) on its own.
Sentry.logger.info("Third-party import finished", {
  "import.source": "aurora",
  "import.entries_received": body.ascents.length,
  "import.imported": imported,
  "import.climbs_created": climbsCreated,
  "import.skipped": skipped,
  "import.skipped.missing_name": skipDetails.missingName,
  "import.skipped.unknown_grade": skipDetails.unknownGrade,
  "import.skipped.invalid_angle": skipDetails.invalidAngle,
  "import.skipped.already_imported": skipDetails.alreadyImported,
});

Audit and access events (creates, updates, deletes, access, permissions)

Audit logs help answer questions like "Who changed this?", "When did it happen?", and "Was this action expected?"

These types of logs can be great for root causing support cases.

Perhaps a user writes in and asks "where the heck did my team's weekly dashboard go?" Because your application logs mutating operations (creates, deletes, updates), you're able to see that another member of their team accidentally deleted the dashboard a few days earlier. You restore the dashboard, let the user know exactly what happened, and have the peace of mind that your application isn't randomly deleting things.

Logging access and permissions can also be a requirement for some standards, like HIPAA.

Note: Audit logs are only one part of meeting compliance requirements. See Sentry and Your Data to learn about the privacy and security controls Sentry provides. If you have complex compliance or privacy requirements, talk to us.

Context surrounding errors and failures

For exceptions, you'll often be better off using Sentry's Capture Error functionality rather than adding a log line. This gives you the benefit of Issue Grouping, triage workflows, Autofix, and other issue-focused features.

However, not every failure should immediately become an error in Sentry. For example, you may rely on a flaky upstream API and allow certain HTTP status codes to be retried N times. When you hit N, you want an error to be raised with Sentry. For attempts before N, a log line explaining why the retry loop is happening can be useful during debugging.

What context might you want to log?

Retry count or attempt number.
Status codes, error codes, or other non-sensitive details returned by upstream services.
Non-sensitive request/response attributes that help explain the failure.
Runtime state relevant to the failure, such as feature flags, configuration.

Now that we've given some recommendations on what to log, let's look at how to structure your log messages.

How to write your log messages

Use structured log messages

Rather than plain-text logs like "DID I GET HERE", prefer structured logs that capture information as consistent key/value pairs.

Structured logs benefit both humans and machines. Consistent fields such as user_id, request_id, feature_flag, or action make debugging easier, and they can be used by logging platforms for search, visualizations, and alerting.

A good log message typically answers three questions:

Who performed the action (for example, the authenticated user).
What happened (a human-readable message and supporting metadata).
When it happened (typically added automatically by the logging system).

Note: For including context about the currently authenticated user, Sentry provides the setUser method.

Add context as a request evolves

Logs should accumulate context as a request moves through your application. Emit that context alongside event-specific metadata in your log messages.

For example, logs emitted before authentication won't contain user information. Later in the request lifecycle, after authentication, user-specific details should be included alongside context specific to the event being logged.

One particularly valuable piece of context is the Trace ID. This allows you to connect a log entry back to a distributed trace, making it easier to understand the sequence of events that led to the log message being emitted.

Good news: Sentry's logs are trace-connected out of the box, so trace context is automatically included when available.

Choose the appropriate log level

Using appropriate log levels is an additional way to convey meaning in your log messages.

Use debug for detailed diagnostic information that is useful during development, or certain investigations. Debug logs are often disabled in production and enabled temporarily when troubleshooting a problem.

Note: Sentry's beforeSendLog method can be used to filter out debug level logs by looking at the level property. beforeSendLog(log) {return log.level !== 'debug'}

Use info for normal application events. Runtime decisions being made, algorithm behaviour, audit logs, these are all candidates for info-level logs.

Use warn for recoverable events that may require attention. A good example might be when an API call to an external service reaches a threshold for latency.

Use error for unexpected failures that are handled gracefully. If a failure results in an exception, prefer Sentry's Capture Error over a duplicate error log.

What not to log

Every function call, or line of code, in your application

Instrumenting every function call is usually better handled by profiling and tracing. Did you know Sentry has profiling and tracing! (Rahul made me say this).

PII and other sensitive information

Whenever logging a piece of information, ask yourself: "What would the impact be if the wrong person gained access to this information?"

Some guidelines:

Prefer opaque user IDs over email addresses or full names when possible.
Passwords, access tokens, API keys, and similar secrets should never appear in logs. Store them only in systems designed for secret storage.
Other types of personal information may also be regulated depending on jurisdiction, including age, gender, and postal code.
Be aware of local and international laws and standards, such as PCI, GDPR, CCPA, and HIPAA, which provide guidance on what should and shouldn't be logged, retained, or exposed.

Note: Sentry has Server-Side Data Scrubbing. If you use structured logging, this can help protect against some common PII and password pitfalls. It is configurable, so you can include additional fields applicable to your application. You can also use beforeSendLog to perform client-side filtering of sensitive information.

TL;DR: Be intentional about what you log. Log the minimum information necessary to debug and operate your application, and understand the requirements that apply to your industry, your country, and your customers' countries.

Large blobs of data (without a specific purpose)

There are legitimate reasons to log large, unstructured blobs of data:

Seeing a full LLM prompt and response may help you understand whether your product is behaving as expected.
Logging a webhook body may help you debug issues with an external integration.

However, logging this type of data has both costs and risks:

Users may include personal or sensitive information in an LLM prompt.
Entire HTTP requests and responses may contain access tokens, secrets, or other sensitive data.
Many logging products, Sentry included, charge based on volume. Ask yourself whether you'll actually use the information you're storing.

For AI assistants, you may also be better off using a purpose-built solution, such as Sentry's Conversations feature, rather than logging entire conversations.

As with the PII discussion, the important takeaway is to be intentional about what you log. Consider the cost and risk associated with the data, and when possible, prefer logging the specific fields you need rather than an entire request, response, or document.

Applying these suggestions to allaboard.dev

Here are some examples of the logs I've added to my aforementioned side project bcoe/allaboard.dev, following the advice from this article:

I'm now much more confident that, when something goes wrong, I have enough context to debug the problem without deploying a new version of the website.

What's next?

I hope this article has given you some inspiration about the what and how of logging, to help speed up debugging next time something tricky happens in production.

If you'd like some help getting started, try getsentry/sentry-for-ai. It can analyze your codebase and suggest an initial set of high-value structured log messages to add.

Try it out

First, run this command to install the Sentry plugin

npx @sentry/ai install

Then paste this in your agent of choice

Please instrument Sentry logging. Include some examples following best practices.

Note: getsentry/sentry-for-ai is being iterated on rapidly and the paths to some skills may change. Keep an eye on the repository for up-to-date install instructions.

Have any feedback, or just want to talk more about logging? Join us on Discord.

Any Apple update can break our app. Here's how we find out first.

Thu, 02 Jul 2026 09:00:00 GMT

This is a guest post by Dan Mindru and Oleh Stasula. Dan is an indie maker, enterprise consultant, and co-host of the Morning Maker Show. Oleh is a full-time indie developer and founder of WinWinKit and Usage.

It feels like with every release, we are walking a tightrope. We need to keep our app lightweight, stable, and performant, all the while depending on APIs that can shift at any moment (without warning, too!).

After 1.6 million downloads, we have a responsibility to our users to keep quality high. We are proud to have kept our rating to 4.7 stars on the App Store, even though we're a tiny team. So how do we do it?

The short answer: a safety net, built with Sentry. This post lays out how we use it at scale, from fixing crashes before users notice, to catching build issues, to getting user feedback that goes beyond the stack trace.

Setting the stage

The application in question is called Usage, a system activity monitor that works across iPhone, iPad, and Mac. It tracks how your device uses its resources: CPU, memory, network, disk, battery, graphics. This plus the rich historical data makes it popular to power users that like to keep a close eye on their device.

This comes with a few challenges. Usage's entire job is to watch your device work without becoming part of the workload. That makes for a strange engineering constraint: every feature we add, every dependency we pull in, every timer we schedule competes with the very thing we promise our users. Nobody wants a system monitor that shows up in its own charts.

And that's not even the half of it. The ground under us isn't stable either. To read some of the data we need, we lean on undocumented APIs in places where Apple doesn't offer a public alternative. That means any OS update can quietly change a data structure under us, on any device, at any time. We don't get a deprecation notice. So we need to stay on top of it at all times.

Usage is also not a single process. The app is built as a small constellation of cooperating components: the main and menu bar apps, the background service, and the widgets. Each has its own lifecycle and its own failure modes. To keep that visible, each component is a separate Sentry project, all grouped under the same workspace. That way crashes and errors stay attributable to the exact process they came from, while we still get a single place to look at the health of the whole system.

Keeping all of this smooth and performant is no small feat, and we lean on a good chunk of Sentry's toolbox to do it:

Crash Monitoring is the baseline that everything else builds on.
Error Monitoring catches the quiet failures, like an OS update changing a data structure we depend on.
Size Analysis diffs every build, so a broken release can't sneak past us twice.
Metrics is how we plan to prove that our optimization work actually works.
User Feedback gives users a direct line to us from inside the app.

Here's how we use each of them.

Crash Monitoring

Crash monitoring is the baseline. Every app needs it, and most of what makes Sentry valuable to us later in this article rests on having the Sentry SDK initialized early in the app's launch.

In each of our targets, Sentry initialization looks pretty standard:



SentrySDK.start { options in
   options.dsn = "___PUBLIC_DSN___"

   // deviceId is a UUID assigned at the first launch and used for:
   // - cross-device sync when enabled
   // - troubleshooting / debugging
   SentrySDK.setUser(User(userId: deviceId))
   SentrySDK.configureScope { scope in
       scope.setTag(value: deviceId, key: "device_id")
   }
}

From this point on, any crash in the app is captured, whether it's a hard signal, an uncaught Swift error, or an NSException. Each one comes with a symbolicated stack trace, the breadcrumbs that led up to it, and the exact release it happened in.

What we actually get from that is a clear picture of stability over time. It's the foundation everything else in this article builds on.

Error Monitoring

With crashes out of the way, let's talk about all subtle errors. A crash at least announces itself. What worries us more is the failure that doesn't: the app keeps running, but somewhere a reading has quietly gone wrong. This usually results in a wrong metric, and a wrong metric is an unhappy user.

For Usage, it's critical to catch these errors early and react quickly. As we mentioned earlier, many parts of the app read system data through undocumented sources and APIs. We don't always know in advance what shape a given reading will take on a given device, OS version, and hardware generation.

Comprehensive error logging is what lets us live with that uncertainty. Every time the app reads a value it doesn't recognize, we capture it as a non-fatal error in Sentry. That covers a missing field, a structure of a type we don't support yet, or a number outside the expected range. This is also where Sentry helps us with privacy. An event only carries the context we choose to attach. We send the shape of the unexpected reading, like the type and fields of a graphics card response. We never send the values, and we never send anything about the user. And if something slips through anyway, beforeSend gives us one last checkpoint to scrub each event before it leaves the device.

One concrete example we hit most often: graphics card readings. The data structure Apple returns for GPU stats has shifted subtly between macOS versions and between hardware generations. When a new Mac shows up with a slightly different shape, we'd be flying blind. Instead, we get a Sentry event the same day with the unexpected structure recorded.

That early warning means support for the new shape usually ships in the next release. By the time most users get that hardware, the fix is already out.

When `Error` is not enough

A stack trace alone is rarely enough to figure out what went wrong with a parsing or decoding error. We almost always want to see the thing that failed alongside the error itself.

Swift's Error protocol doesn't carry an arbitrary payload by default, so we add one. A small wrapper struct and a single extension method are enough:

struct ErrorWithData: Error {
    let error: Error
    let data: Any
}

extension Error {

   func with(data optionalData: Any?) -> Error {
        if let data = optionalData {
            return ErrorWithData(
                error: self,
                data: data
            )
        }
        return self
    }
}

The with(data:) method is the call-site sugar: it lets us tack context onto any error without rewriting our error types, and it gracefully no-ops when there's nothing to attach. A typical use looks like:

throw GraphicsHelperFetcherError.displayMissingProperty("sppci_model").with(data: rawResponse)

Then at the capture site, we unwrap the data and put it on the Sentry scope as an extra:

SentrySDK.capture(error: actualError) { scope in
    ...
    if let data = (error as? ErrorWithData)?.data {
       scope.setExtra(value: data, key: "data")
    }
}

In Sentry, the data ends up as a labeled field on the event, right next to the stack trace. For the kinds of errors we deal with, unrecognized system readings and unexpected field shapes, that one field is often what makes the difference.

Here's that pattern in action. The screenshots below show a real Sentry event from the macOS app: a parsing error on a graphics reading where one of the display objects came back without a property we expected. The stack trace tells us where it failed, but the data field tells us why: the raw structure is right there, missing the field, on a GPU and macOS combination we hadn't seen before. That's our signal to update our handling of display objects in graphics data, and we can usually ship the fix in the next release.

Size Analysis

Crash and error monitoring watch the app while it runs. They can't catch a build that was broken before anyone ever launched it. We learned that one the hard way.

A while back, a refactor accidentally removed one of the app's localizations. Somehow the diff didn't go through our usual review process, and a build with the broken refactor was uploaded and selected for release. Once it hit production, the effect was immediate and not subtle: active users in the affected locales fell off a cliff before we understood why.

While rare, these things can happen on any team. We needed a second line of defense beyond reviewing diffs.

Sentry's Size Analysis turned out to be exactly that. It runs on every release build, attaches a size report to the same version+build release tag the rest of Sentry already uses, and diffs the new build against the previous one. If a localization file, an asset, or an entire bundle resource disappears, the diff makes it impossible to miss. Same goes for the inverse: a release that mysteriously grew has its cause sitting right there in the breakdown.

Even though Size Analysis is (probably) meant for only keeping app size in check (and we use it for that too!), what sold us is using it as a regression gate. We can't guarantee that a human or automated process will catch these issues in a review, and size analysis works well as an additional sanity check.

On top of the size reports, we've set up a Sentry monitor that watches the delta between releases and alerts us whenever a build comes in noticeably heavier or lighter than the previous one. The "lighter" direction is what makes the localization incident obvious; the "heavier" direction catches bloat creeping in. Either way, now we can rest assured that we'll know about these issues before they become a problem.

Metrics

Everything above is about catching what goes wrong. The last piece is proving what goes right.

Metrics is a newer Sentry feature that we're in the middle of adopting. For an app like Usage, performance and resource footprint aren't just a nice-to-have; they're the product. So being able to emit our own counters and gauges from anywhere in the codebase, and see them sitting next to crashes and errors, is a big deal.

We're instrumenting the things we already care about, like sampling latency, background work duration, and sync intervals, so Metrics can confirm that our optimization work is actually moving those numbers.

So far the results are promising. We'll write a proper deep dive once we've used it extensively.

User Feedback

Not everything users do shows up as a crash or error. Sometimes the app is technically healthy and someone is still staring at a chart that doesn't look right. For those cases, we'd rather they tell us directly.

We first tried Sentry's User Feedback in our other product, WinWinKit, and once we saw the value we knew we had to immediately add it to Usage too.

It became one of the bigger drivers of faster iteration and stronger user engagement. It's an easy one for us to recommend. With a few lines of code you get a small in-app form that lets users send feedback without leaving the app. The feedback lands in the same workspace as our crashes and errors, tagged with the same release.

If you're on the fence about it, we can definitely recommend it. Every report makes the next build a little better than it would have been.

Wrapping up

We're still walking the tightrope, but these days we actually enjoy the view. Apple will ship another update, some struct will grow a new shape, and a Mac we've never touched will send us bytes we've never seen. Bring it on!

If you're building something that depends on a platform you don't control (and honestly, who isn't?), our advice is simple: have as many safety nets as you can. Your users will thank you for it!

Reading the agent traces is how you make the call your eval can't

Wed, 01 Jul 2026 09:00:00 GMT

Remember being excited (or dreading, depending on the stage of your career and the company you worked at) about writing unit tests? Or sweating all the details in your end-to-end and integration tests you were sure covered all the use cases your users would hit?

These days a lot of UIs are slowly being replaced by a single input field and an agent that promises to deliver the same value a UI would, but with the elegance and pun-ness of a “Jarvis”.

We craft their SOUL.md and their MEMORY.md and the system prompt. We pretend we know what we’re doing setting up evals with prompts we know are not how our users will interact with the agent, but we set the threshold and the confidence score comes back satisfactory and we approve and deploy. Job’s done, right?

Not quite.

Sentry is attending AI Engineer World's Fair this week and I decided to build a little schedule builder with an agent to help people put together their itineraries. (Shout out to Swyx for providing the data and even the embeddings for all the speakers, talks and tracks.)

I wanted to make sure that this is somewhat scalable, and thanks to the AI SDK and Vercel’s AI Gateway, it was pretty easy to configure the agent to use some open weight, incredibly cheap models for anonymous visitors, and more beefy, SOTA-ish models for people that signed up.

Surely, with tool calling, and a great system prompt, there is no way even the small-but-mighty model would hallucinate, right? Right???

“Who are some famous speakers?”

The assistant has a router that reads each question and sends it down one of two paths: an "info" path and a "search" path. My speakers question went to the info path, which has exactly one data tool, getTracks. Here is everything getTracks returns:

[
  {
    "id": "agentic-commerce",
    "name": "Agentic Commerce",
    "color": "#22c55e",
    "description": "Agentic Commerce sessions at AI Engineer World's Fair 2026 in San Francisco."
  }
]

In the confident fashion, that most coding agents will proceed to tell you the most frustrating half-fact / blatant lie, it told me that Sam Altman and Jensen Huang will be on the main stage. One of the names it gave me, "Chris Hagen, Founder of Stability AI," isn't even a real person.

When I asked how it got Sam Altman, it doubled down:

I didn't "guess" Sam Altman. I pulled him straight from the official conference data that the API provides. I called the getTracks function, which returns every track that's been scheduled for the fair, along with the speakers listed for each session.

getTracks does not return speakers. It invented the data, then invented a source for the data.

The trace lists "Used Tools: getTracks," which is the part that makes this sneaky. A tool ran, so the answer reads as grounded. You only catch it by opening that tool call and seeing tracks where speakers should be.

Hindsight is always 20/20

An eval probably would have caught this one. But would I have thought to write it in the first place? The agent named people the app's speakers table has never heard of. A groundedness check, assert that every person the answer names shows up in the tool output or the speakers table and fail when one doesn't, would have flagged this trace. You can write exactly that as a vitest-eval with a small custom scorer that diffs the named entities against the database, no LLM judge required.

If that check had been running in CI, it might well have caught the fabrication before I did.

Nobody adds a "don't name speakers that aren't in the database" assertion on day one. You add it after you watch a model do it, then double down when you question it. The eval is the thing you write down afterward. Reading is what tells you it is worth writing. I have not heard of eval-driven development just yet, but I'll be damned.

You don't have to wait for production to catch the whole category, though, even if you wait to catch the specific case. You can't enumerate how people will phrase questions, so don't try to test the open world; test the contract you designed instead. That's the handful of intents the agent is meant to handle, plus the questions whose answer isn't in your data at all. "Who are the famous speakers?" against an empty speakers table is exactly that second kind, an out-of-data case you write on purpose to see whether a model grounds its answer or fabricates one. Run it against the open model before you ship and it fails the same way, no live traffic required.

The decision an eval can't make for you

Run the groundedness check across the open model and Claude and you get the quality gap, and the cost and latency are already on every trace, so you can lay the whole cost, quality, and speed tradeoff out as a table.

What the eval won't do is pick the point on it. It can tell me the open model scores lower at a fraction of the price; it can't tell me whether that lower score is acceptable for an anonymous user asking about a conference, or worth paying to fix. A failing eval says "wrong." It doesn't say "move anonymous users to a pricier model," or "this is fine for kick-the-tires traffic and not worth the spend." That is a judgment call about what a wrong answer costs and who's on the other end of it, and it stays with me.

So once I'd read enough traces, the fix wasn't just one thing. It was a menu of options, and every one is a tradeoff:

Give the free tier a better model. Fixes the quality, raises the bill and the latency, on exactly the traffic I was trying to keep cheap.
Fix the routing so a "who's speaking" question never lands on a path that can't answer it. Cheapest fix, narrowest.
Tighten the prompt: never name a session, speaker, or affiliation a tool didn't return, and if you can't answer, say so.
Write the groundedness eval so it can't regress quietly later.
Decide it's fine. It is an anonymous user asking about a conference, and "I can't find that" is a perfectly good answer to ship for free.

I kept the cheap model, fixed the routing, tightened the prompt, and wrote the eval. I could only make that call because I'd read enough to know how badly it landed.

And once you read a few agent traces, you start to develop a sense of what feels right, what feels wrong and things to look out for. Things an eval would not be able to tell you.

You start to develop “taste” (is this overplayed yet?).

Make the traces easy to find

None of this works if you can't find the trace in the first place, which is the part of agent tracing nobody demos.

My agent records inputs and outputs in its telemetry, so the whole exchange and every tool result land in Sentry with a stable conversation_id attached:

experimental_telemetry: {
  isEnabled: true,
  functionId: "conference-scheduler.schedule",
  recordInputs: true,
  recordOutputs: true,
  metadata: {
    agent: "schedule",
    model_id: config.id,
    conversation_id: context.conversationId,
  },
},

A teammate went further on their own agent. They log the first user message with a few attributes and a link straight back to the trace, so when something looks off they search the text instead of their memory:

Sentry.logger.info("agent conversation started", {
  conversation_id: conversationId,
  first_message: messages[0].content,
  user_tier: identity.tier,
  conversation_url: `https://your-app.com/admin/conversations/${conversationId}`,
});

The useful part is that the agent trace lands next to the errors, performance data, and logs from the same request. When an answer looks wrong, you can read it and then follow it to the empty query or the bad route behind it, which is the step a standalone eval score leaves you to guess at.

Read the agent traces before you reach for the fix

Picking a model, routing a question, writing a prompt, deciding what to test: these are all tradeoffs, and none of them come with a dashboard that tells you whether you got them right. An eval will tell you when a known thing regresses. It will not tell you what you haven't thought to check yet, and it will not make the cost-versus-quality call for the people on your free tier.

So before you swap a model or add a judge, go read some traces. That is less manual than it used to be. Point your coding agent at the Sentry MCP and it can run search_ai_conversations to surface the traces worth reading, then get_ai_conversation_details to pull the transcript with every tool call and the input and output it actually returned.

Read the traces, then make the call your eval can't.

Next.js already traces your requests. Here's how to export them with OpenTelemetry.

Mon, 29 Jun 2026 09:00:00 GMT

Traces are a goldmine of information that can help you, or your AI, find slow pages and fix them.

Next.js comes out of the box with support for tracing. Incoming requests, fetch() calls, middleware, and server-side rendering are all wired up and ready to send traces to any OpenTelemetry-compatible backend.

The catch is, unless you configure an exporter, you'll never see those traces.

With a few lines of code and some help from the @vercel/otel library, your app can export those traces to any platform that accepts OpenTelemetry data, including Sentry.

(And if you're trying to decide between OTLP and the Sentry SDK, we'll cover that too.)

Why Next.js traces matter

When a page in your Next.js app is slow, the hard part is figuring out which part of the request is responsible. It might be middleware, server-side rendering, an API route, a database query, an upstream fetch() call, or a custom function you wrote. Without a trace of how the request actually executed, you end up working backwards from symptoms: reproducing locally, adding logs, guessing at likely bottlenecks, and hoping production behaves the same way your machine does.

With tracing, each API call, page load, database query, and more, is recorded as a span in an execution timeline. A trace groups all of the spans from a single request into a waterfall, so you can see exactly where time was spent.

In this trace, the top-level GET /api/auth/[...nextauth] span represents the incoming request. Under it, Next.js creates additional spans for every step in that request; resolving page components, executing the API route, and starting the response. With this full hierarchy, we can see exactly where time was spent during that request.

In the Node runtime, you'll begin to enrich this timeline with your own custom spans that add more app-specific context to each trace (we'll walk through some examples down below).

Edge runtime traces can still include automatic spans from Next.js through @vercel/otel, but @vercel/otel does not support custom spans on Edge.

OpenTelemetry is an open standard for recording and transporting a variety of telemetry data, like traces, to any backend that will support it. In order to get this data out of your app, you just need to tell OpenTelemetry where to send it.

Configuring OpenTelemetry for Next.js

Next.js already has server-side tracing enabled, OpenTelemetry just needs to know where to send it.

Vercel offers a library, @vercel/otel, that configures the OpenTelemetry SDK for you and handles the differences between the Node and Edge runtimes automatically. We'll use it to configure the SDK and export the traces to Sentry.

This is particularly useful if you have an existing OpenTelemetry stack, and are self-hosting Next.js. If you are hosting on Vercel, there are other options available.

Sentry provides a direct OTLP endpoint that you can use to send OpenTelemetry data to, but you can use any OTLP-compatible backend.

// instrumentation.ts



  registerOTel({ serviceName: "next-app" });
}

Next.js automatically loads instrumentation.ts from the project root at startup. The register function runs once before any request is handled, providing a good hook to configure the OpenTelemetry SDK.

That's essentially all you need to add to your app. Exporting the traces to Sentry only requires two environment variables, which we'll cover in a second.

You can read the full setup guide for @vercel/otel in the Vercel docs.

Adding your own spans

Even though Next.js comes pre-instrumented with tracing, the spans it emits are generic and don't include any unique attributes about your specific business logic. It's a good and useful starting point, but to really get the most out of tracing, you'll want to add your own spans around critical parts of your application.

Add your own spans around important business operations that you would name during an incident: generating an invoice, charging a card, resizing an uploaded image, calling an AI model, scoring recommendations, syncing a customer to a third-party API, etc.

Don't wrap every helper function. Start with high-level operations that impact user experience and business metrics.

For span names, use consistent action-oriented names like invoice.generate-pdf or ai.summarize-ticket. Dotted notation for naming is a common convention. It's a useful way to group related spans by domain, and you can use them to scope your search when aggregating later. For example, you might start by investigating all invoice spans, and then narrow down to a specific operation like invoice.generate-pdf.

For attributes, try to add context that will help you filter and group traces when investigating performance; feature flags, plan tiers, batch sizes, item counts, payload sizes, generated file sizes, etc. Avoid raw user IDs, emails, secrets, prompts, or anything with very high cardinality unless your backend explicitly supports that use case.

Let's look at some spans we might add to an invoice generator, for example:



const tracer = trace.getTracer("next-app");


  return tracer.startActiveSpan("invoice.generate-pdf", async (span) => {
    try {
      span.setAttribute("invoice.line_items_count", invoice.lineItems.length);
      span.setAttribute("invoice.locale", invoice.locale);
      span.setAttribute("invoice.template", invoice.template);
      span.setAttribute("customer.plan", invoice.customer.plan);

      const pdf = await renderInvoicePdf(invoice);

      span.setAttribute("invoice.pdf_size_bytes", pdf.byteLength);

      return pdf;
    } finally {
      span.end();
    }
  });
}

Now, if invoice generation gets slow, you can search for invoice.generate-pdf, group those spans by template, locale, or customer plan, and quickly see whether large invoices, a specific PDF template, or one customer segment is causing the slowdown.

An important caveat of custom spans for @vercel/otel is that they are only supported in the Node runtime. The @vercel/otel library does instrument automatic spans in the Edge runtime, but you cannot add your own. To add custom spans in the Edge runtime, consider using the @sentry/nextjs SDK instead.

Sending traces to an OTLP backend

OTLP is the standard protocol for transporting OpenTelemetry traces. An OTLP backend is the destination that receives those traces, stores them, and gives you a UI for searching, filtering, and viewing trace waterfalls. That could be an observability platform like Sentry, or another OpenTelemetry-compatible service.

@vercel/otel expects and honors the standard OTEL_EXPORTER_OTLP_* environment variables for configuring the exporter. So, to export to Sentry's direct OTLP endpoint, you'll need to set two environment variables: an endpoint URL and an authentication header.

You'll find your endpoint URL and public key under Project Settings → Client Keys (DSN).

Set two environment variables:

Set those wherever you deploy your app so they exist at runtime. Once set, you should start immediately seeing traces populating your Sentry Trace View. No Sentry SDK, no collector, minimal code change.

Choosing between OTLP and the Sentry SDK

OpenTelemetry is vendor-neutral and excellent when you are already deep in the ecosystem. But, if you're configuring tracing for the first time, my recommendation, especially for Next.js, is to use the Sentry SDK.

@vercel/otel is easy to configure, but it doesn't capture the whole picture. It can export useful server-side spans from the Node and Edge runtimes, but it won't give you the browser side of the trace, Sentry issues, or the rest of the debugging context that comes from the SDK.

Feature	`@vercel/otel` direct to Sentry OTLP	`@sentry/nextjs` SDK
Node server tracing	Yes	Yes
Edge runtime tracing	Automatic server spans only	Yes
Custom spans	Node runtime only	Node, Edge, and browser
Browser tracing	No	Yes
Error monitoring	No	Yes
Source-mapped stack traces	No	Yes
Session Replay	No	Yes
Logs	No	Yes

The practical choice is simpler than the number of integrations makes it look. If your team relies on Sentry to find, group, and debug production issues, use the SDK. If you already have an OpenTelemetry pipeline, want to migrate in stages, or only need standards-based server traces in Sentry, direct OTLP is the leaner option.

One compatibility note: don't initialize @vercel/otel and the Sentry SDK's OpenTelemetry setup in the same app. Both register a tracer provider. If you already manage your own NodeTracerProvider and want to add Sentry alongside it, set skipOpenTelemetrySetup: true in Sentry.init() and follow the custom setup guide.

If your app runs on Vercel and you want platform-level forwarding instead of app-level exporter configuration, Vercel Drains can send logs and traces to Sentry too. Just remember that drains and direct OTLP still do not replace SDK-based error monitoring.

Next steps

Once your Next.js traces are flowing into Sentry, turn them into something your team can act on. Use Monitors to watch the routes and operations that matter most: auth flows, checkout, dashboards, API routes, and any page users complain about being slow. Monitors can evaluate thresholds on spans and other application signals, then turn those conditions into issues when they cross the line.

Pair those monitors with Alerts so the right people hear about new or worsening issues in Slack, email, PagerDuty, webhooks, or whatever workflow your team uses. That gives you a path from trace data, to a triageable issue, to the action your team needs to take.

Then build dashboards around the questions you want answered every week: which routes are slowest, which custom spans are regressing, and whether performance changed after a deploy.

Traces are most useful when they become part of your operational loop: monitor the important paths, alert when they drift, use dashboards to see whether the fixes actually helped, and try Seer Agent to automatically inspect traces and explain what's causing a slow or failing request.

Better, faster, less wrong: Enhancing issue grouping

Fri, 12 Jun 2026 09:00:00 GMT

Sentry's job is to tell you when your app breaks. To do that, we group individual errors into issues. First by fingerprinting, which lexically matches errors based on their structure, then by an AI fallback: when fingerprinting can't find a match, an ML model compares the new error's stacktrace against existing issues and merges it if they're semantically similar. We recently upgraded the model, preventing 20% more duplicate issues from being created while halving the rate of incorrect merges.

AI-powered issue grouping is enabled by default and live for all Sentry customers.

What makes grouping hard

We talked about v1 of AI grouping in Using a transformer-based text embeddings model to reduce Sentry alerts by 40% and cut through noise.

A good grouping algorithm minimizes both undergrouping and overgrouping. Minimizing undergrouping means Sentry isn't spamming your feed with new issues for the same underlying problem. Minimizing overgrouping means Sentry always tells you about new categories of errors your app is experiencing. Striking the right balance between these can be tricky and subjective.

Overgrouping is arguably the more sinister failure mode. When Sentry incorrectly merges an error into an issue, we're hiding a problem that should be addressed by a different work stream; this error may have a different priority, root cause, and fix.

To demonstrate how easy it is to mess this up, here's a real example of 2 nearly identical stacktraces from the Sentry repo that have distinct root causes:

# Stacktrace A
ReadTimeoutError / TimeoutError
  autofix.py::generate_summary_and_run_automation
  issue_summary.py::get_issue_summary → _generate_summary
  → run_automation → get_autofix_state        # <-- diverges here
    utils.py::make_get_autofix_state_request
    signed_seer_api.py::make_signed_seer_api_request → urlopen

# Stacktrace B
ReadTimeoutError / TimeoutError
  autofix.py::generate_summary_and_run_automation
  issue_summary.py::get_issue_summary → _generate_summary
  → run_automation → get_and_update_group_fixability_score  # <-- diverges here
    issue_summary.py::_generate_fixability_score
    signed_seer_api.py::make_signed_seer_api_request → urlopen

Both errors are timeouts from the Seer Autofix feature and share the same request path. The needle in the haystack is in two stacktrace frames. The first timeout is from the get_autofix_state flow: a DB query that'll run on a standard web server. The second timeout is from the _generate_fixability_score flow: an ML model call that'll run on a GPU server through a separate connection pool with a 2x higher timeout threshold. Improving client-side and server-side handling of these requests entails independent work. Yet the v1 model merges these errors into a single issue. The v2 model separates them.

Grouping stacktraces is a nuanced task, not the kind that embeddings APIs are trained to handle. The heavyweight gemini-embeddings-2 model, for example, flops on our task. While Jina AI's code embeddings model was accurate and efficient for v1 of AI grouping, we knew we could do better than anything off the shelf. We're sitting on a trove of production stacktraces, plus two years of v1 failure modes the team has internalized as tribal knowledge. LLMs let us apply that knowledge at scale through a labeling algorithm we ran on hundreds of thousands of stacktraces. The v2 model is trained on those labels and has been powering AI grouping since April.

Here's how v2 is doing in production

We're making fewer issues

AI grouping is preventing 70% of all new issues from being created, up from 50% before we started rolling out v2 on April 22. Among 3,800 large Sentry projects (projects ingesting at least 100 new issues/day with stable error volume before and after v2), 18% saw their rate of AI-prevented issues double since v2.

Overgrouping has been cut in half

v1's overgrouping rate, or its rate of incorrect merges, is 8%. While this number doesn't sound terrible in the aggregate, the kicker is that the v1 model has a tendency to overgroup errors from certain platforms. Platform biases can significantly harm the Sentry experience at the project level. In a small but focused exploration, we found projects whose v1 overgrouping rates ranged from 30% to 60%. It's not uncommon to find issues in these projects that are bloated with errors representing many distinct root causes.

v2's overgrouping rate is 4%, and is low across all platforms. All projects in the cohort above now overgroup 2-15% of the time while maintaining or improving on v1 merge rates.

v2 improves across every platform where v1 significantly overgrouped. Merge rate is the fraction of new errors which are merged into an existing issue. The overgrouping rate is the fraction of these merges which are incorrect; the error is in an issue that it doesn't truly belong to.

How we trained v2

Sampling and labeling data were, by far, the most critical parts of our training pipeline. We sampled stacktraces from hundreds of consenting Sentry projects, selecting for a wide variety in project merge rates and stacktrace lengths, and partially stratified by platform to counter Sentry's majority JavaScript makeup. We also increased sample weights for stacktrace pairs that were closer to the v1 model's decision boundary, based on the hypothesis that these pairs are the ones where a successor stands to gain the most.

We labeled the data by prompting Claude Sonnet 4.5 with a thinking budget of 1,024 tokens. The prompt was carefully iterated to follow Sentry's guidelines around issue grouping, including weighing the error's underlying cause over surface-level semantics. We measured the prompt's accuracy against expert-labeled stacktrace pairs from internal Sentry projects. The expert labelers were Sentry's grouping czars: employees who have mulled over stacktrace similarity for years. We err on the side of avoiding overgrouping in our own labels and instructed Claude to do the same.

We then trained lightonai/modernbert-embed-large on these labeled stacktrace pairs. The training data contains hundreds of thousands of pairs of stacktraces ranging from 10 to 8192 tokens. Most training runs tested genuine improvement ideas. Some runs were for the love of the game. A couple of unique training choices are that we use a loss function from 2005, group the dataloader's scan order to deduplicate forwards passes, and we do something funny with DDP after losing an afternoon failing to install flash-attn for varlen. Our findings, including interesting experiments that did not yield improvements, are documented in the grouping-trainer repo.

Since we were running experiments in parallel to eke out accuracy, we built some baby training infra to reduce headaches induced by GPU stockouts. We've gotten up to 20 L4, A100, and H100 GPUs going at the same time (a modest fleet for a team of our size), and all running within 30 minutes of being triggered.

Our training, offline eval, and baby infra code is available at getsentry/grouping-trainer.

On the evaluation side, we now measure overgrouping in production. Overgrouping has been a silent but deadly failure mode in the past. Uncovering it used to require manually scrutinizing merged issues in the UI based on customer reports. Today, we have a pipeline that can batch-label 1000s of merged issues from a SQL query.

Modernizing v2 inference

We also upgraded the v2 model's inference to reduce its overhead on Sentry's ultra-hot error ingestion path. AI grouping v2 is 6x faster than v1, uses less GPU memory, and saves hundreds of GBs of DB space.

The most impactful modernization is embedding truncation. Because the v2 model is trained via Matryoshka Representation Learning, truncating v2 embeddings from 768 dimensions to 64 sacrificed just 2% in accuracy while reducing p50 HNSW lookup times by 4x, p50 insertion times by 20x, and pgvector DB storage by 12x.

We also run the model in bfloat16 and enabled PyTorch's SDPA to get an easy inference speedup and eliminate CUDA OOMs in production. These changes are a one-liner thanks to Hugging Face:

 model = SentenceTransformer(
     "lightonai/modernbert-embed-large",
+    model_kwargs={"dtype": torch.bfloat16, "attn_implementation": "sdpa"}
 )

Finally, we compiled the model to fit our latency-sensitive + plain PyTorch server setup, reducing p50 model inference latency by almost 3x compared to no compilation. In case you have a similar setup and a long-tailed token distribution, we benchmarked this CUDA graph compilation strategy and made it available on GitHub.

All of these changes were stress-tested offline by running them through a load test that closely mimics production: start with a pgvector DB backfilled with real projects' stacktraces, and concurrently send the app real, new stacktraces from those projects.

How we've enabled seamless model upgrades

Upgrading ML models for stateless inference is conceptually simple: load in the new model and serve it. AI grouping is far from stateless: it inserts embeddings at a rate proportional to issue creation, and stores this data for up to 90 days. Naively replacing the v1 model with the v2 one would cause a massive surge in new issues, as v2 has nothing in the database to match against. This meant we needed to ship the new model and backfill its embeddings without hurting the customer experience.

We considered a full backfill (like v1, which took months), waiting 90 days to accumulate v2 embeddings before switching, or going live with v2 immediately and falling back to v1 whenever v2 doesn't have enough data. We went with option 3: customers get v2's benefits from day one, and v2 can only improve on v1's decisions, never undo them.

The mechanism hinges on two parameters we added to Seer's grouping API: model and training_mode. When a project is opted into v2 via a feature flag, Sentry sends stacktraces to Seer with model=v2. Seer searches the v2 embedding space first; if it comes up empty, it falls back to v1.

There's a subtlety, though: Seer uses threshold-gated indexing, which means embeddings are only stored when no sufficiently close match already exists in the index. This keeps the HNSW graph compact and improves search efficiency: since we only need any match within the threshold rather than the true nearest neighbor, a sparser graph with bounded edges (m=16) is all we need. The consequence, however, is that v2's corpus would only grow from genuinely new events, leaving existing groups without v2 representations.

That's where training_mode comes in. For group hashes that were previously only sent under v1, Sentry fires a request with training_mode=true. Seer stores the v2 embedding but returns no grouping result, which bypasses near-duplicate suppression to deliberately backfill the index. This populates v2's database in real time, piggybacking on live traffic instead of running a separate job.

We rolled out project by project, starting internally. The entire migration took about 6 weeks with zero customer-reported regressions. And the infrastructure is reusable. If we train a v3 tomorrow, the upgrade path is the same: add a column, flip a flag, and let the fallback chain handle the transition.

What's next?

Labeling more data and finetuning a much bigger model will help. A more interesting line of research is to improve the model's input. Today, the model only looks at the error's stacktrace. A smarter model should be able to use signals attached to the error on ingestion, e.g., the transaction and variable values. Going a step further, what if Sentry accumulated knowledge about your app and attached relevant context dynamically: what's the higher-level purpose of a transaction, how do downstream users experience an error? We're currently exploring this context accumulation problem through Seer.

In the meantime, v2 will be chugging along, routing your stacktraces to the right issue.

Catch visual regressions with Snapshots, now in beta

Thu, 11 Jun 2026 09:00:00 GMT

Sentry Snapshots diffs screenshots on every commit and blocks the PR if there are any visual changes so you can confirm they're intentional. Users don't interact with code, they interact with something they can see and touch. Snapshots gives you a lightweight way to test it.

It's easier than ever to change code. It's also easier than ever to trade quality for speed. Modern codebases need guardrails to ensure correctness. Our goal with Snapshots is to be a check for your code and a resource to improve your workflow.

What is snapshot testing

The core flow of snapshot testing is simple:

Make a code change
Generate screenshots of your application
Compare those screenshots against a baseline
Surface any changes

In Sentry Snapshots, you upload screenshots, we diff them, then post in the PR if there are any diffs.

You can then jump into the UX to see what exactly those changes are:

This simple workflow adds an axis of visual coverage. Test your application looks as expected in different themes, languages, or viewports. Snapshot testing validates that you're not changing more than intended.

How Sentry Snapshots works with agents

Snapshot testing as it's always existed, as a guardrail for visual changes, is especially helpful for agents. Maybe you have a haphazard prompt, agent makes a change, run snapshot testing, block PR if a change is detected.

But Snapshots can also be an artifact that can be used by agents. Here's a runthrough of how we recently used Snapshots to help make a visual change to Snapshots itself.

The issue

Multiple users gave similar feedback around our "Snapshot Toolbar":

Being confused at the initial red "diff mask" on a snapshot
Wanting to hide the mask (this was already possible)
Wanting to change "diff" views, but not being sure how to

Basically, we had discoverability issues for features that exist.

Snapshots as context

The first step was to increase our coverage. We had some tests in place, but wanted to add screenshots for different active states in our component (there are slight differences depending on the active view):

To add to our test, we obviously need to find where our test is.

Sentry Snapshots lets you add context metadata to every image. This can be whatever you want and is designed to provide information to agents. In Sentry's dogfooding of Snapshots, we pass a source_test_file, which is just a path to where the file is.

To add more snapshot tests, all I had to do was copy-paste the metadata to an LLM and explain what I wanted to do:

Find this snapshot test and add states for the different diff views
{
  "display_name": "all controls @md",
  "group": "SnapshotsToolbar/light",
  "image_file_name": "static/app/views/preprod/snapshots/main/snapshotstoolbar-light-allcontrols-md.png",
  "width": 1984,
  "height": 90,
  "tags": {
    "area": "snapshots",
    "theme": "light",
    "viewport": "md"
  },
  "context": {
    "test_file_path": "static/app/views/preprod/snapshots/main/snapshotsToolbar.snapshots.tsx"
  }
}

If you have a good framework for writing snapshot tests, agents are very good at writing more, especially if you tell them exactly where to look. Here's the new tests we produced (unique UI highlighted for example purposes):

In this case, I was doing work related to snapshot tests so copy-pasting was easy, but this data is also available via the sentry-mcp and our REST API to use in other scenarios. I used the literal context prop to direct the agent, but you also have access to the produced images and diffs to pass in, which are a helpful reference for agents.

Reviewing diffs from CI

Our initial stab to improve discoverability was to show the active label. But this didn't do as much as we wanted, specifically for the overlay mask.

We passed in the link to the snapshot to the LLM:

I want to make the color picker more noticeable, but it's still too subtle.
Make it have a light border on dark theme and dark border on light theme:
https://sentry.sentry.io/preprod/snapshots/299186/?selectedTypes=changed&selectedSnapshot=static%2Fapp%2Fviews%2Fpreprod%2Fsnapshots%2Fmain%2Fsnapshotstoolbar-dark-allcontrols-sm.png

This triggered the agent to use the sentry-mcp to get the snapshot resource, including:

Base image
Head image
Diff mask
Metadata

The agent easily made the change. Realistically, this simple change probably could have done without the resource, but the screenshot data + context metadata provides context specific to the task. The context includes narrowed screenshot data, as well as your local PR information. This is a repeatable, programmatic way of hitting your LLM with a screenshot + "do the thing."

Snapshots as local verification

To finish the loop, we need our agent to be able to produce and diff snapshots. Producing snapshots is bespoke to the repo. The sentry-cli lets you download the baseline images and diff your local set against them. We can have our agent do the diffing and then expose the results to us (or if you also like to live dangerously, have the LLM judge and commit if it looks intended).

The local flow is roughly:

# 1. download base
sentry-cli snapshots download --app-id {your-id} --branch {main}
# 2. generate snapshots locally
# 3. diff snapshots
sentry-cli snapshots diff ./snapshots-base path-to-local --fail-on-diff --selective

This can be useful independent of an agent, but you can also have your agent do this as part of the pre-commit process or in a prompt.

The local diff is exactly as expected. We pushed up the new commit, where Snapshots in CI also flagged the diff. We approved, merged, and voila:

This was a simple change, but it's easy to see how all of these workflows can be extended. Snapshots can be used as hyper-relevant context, which your agent can query against, make changes, and run verification loops locally.

For full reference, read our local testing documentation.

Snapshot testing isn't perfect

Snapshot testing is not for everyone, nor is it a good fit for every repo. There is a non-zero chance you've read this far out of anger, seething to yourself that snapshot testing is a useless PITA. It can be more trouble than it's worth to produce good screenshots. You may have fought with managing "goldens" or git-lfs in the past.

We agree, which is why we first built Snapshots at Emerge Tools. Our original Snapshots product focused on mobile apps and abstracted all the painful parts away and was used by companies like OpenAI to build out ChatGPT and Codex. Sentry Snapshots takes what we thought worked well and extends the functionality to any platform.

It might be true that your code is not easy to snapshot; we're in the midst of improving how we use Snapshots at Sentry ourselves. But we've seen how effective a snapshot testing workflow can be and are excited to keep building it out.

Getting started with Snapshots

Sentry's motto is "code breaks, fix it faster." Snapshots is a step to prevent it from breaking at all.

Snapshots is now available in beta for all users. There are recommended workflows for iOS and Android to go from Previews to Screenshots (the iOS repo was recently highlighted as part of Codex's new iOS functionality). You can use Snapshots on any platform with a frontend.

Have questions or feedback?

Join the conversation in our Discord
Email us at mobile-team@sentry.io

New to Sentry?

Try Sentry for free

Works on my machine: how we use AI to reproduce reported bugs

Mon, 08 Jun 2026 09:00:00 GMT

Sentry's SDK teams maintain and support SDKs for a vast ecosystem of languages and frameworks. See our release registry for a source of truth. We're currently at 159 published packages across the entire ecosystem. If you use it, we probably support it.

All of these SDKs are open source and have their own GitHub repositories that we maintain on a daily basis. And like any other open source project, we get tons of bug reports and issues on these.

In this post, I'll talk about a Claude skill we've been leveraging to help make our reproduction flow smoother and reduce triage time and fatigue.

Bug triage flow

Sometimes bugs are easy to fix - could have been a missing null check, a missing conditional branch or some other small oversight.

Other times, they aren't so easy for a plethora of reasons:

Tedious setup, or "boilerplate", just to get the environment ready
Esoteric code paths
Legacy versions
Edge case interactions no one thought of
Data races and other concurrency problems
Forked libraries with different contracts

Boilerplate

Particularly for our SDK bugs, the boilerplate factor is quite annoying. Let's take a recent example. To reproduce this, we would need to setup the following:

A Python venv with the correct version
A new Django boilerplate app with the correct version
A Sentry SDK with the correct version
Create a Django View that reproduces and showcases the exact problem which is applicable only to HTTPS proxies
Run everything, trigger the view and hope that it shows the problem in question

All of this is necessary just to acknowledge that the problem the original user reported is real and replicable. Once reproduced, it's typically much easier to roll out the actual fix.

Reproduction papertrail

Another recurring discussion within the teams was how to keep track of all these one-off boilerplate apps that we used to test SDK logic, and reproduce/fix problems.

Ideally we would have a shared repository of these apps with backlinks to the issues, but no one wanted the burden of maintaining yet another collection of apps on top of everything else we already do. Several SDK engineers had their own ad-hoc collection of apps they used for their day-to-day SDK development.

`repro` skill + repository

Enter LLMs. Turns out LLMs are pretty good at doing some of the tedious stuff mentioned above.

Even if they cannot get to the root of a hairy problem, they at least set up the boilerplate and give me a playground with all the correct parameters which I can move forward with, massively reducing tedium.

So I wrote up and iterated on a Claude skill that:

Takes a GitHub issue URL as input
Parses the SDK language, issue number
Gathers metadata on language version, framework version, SDK version
Makes a new directory and branch from the language/issue-number
Attempts to create a minimal reproduction using standard tooling for the language (uv, npm, bundle, etc.)
Tries to run the reproduction, bails out if it's too complicated
Writes up clear instructions for running the reproduction
Makes a PR
Optionally adds a backlink to the PR to the original user issue (using Claude's AskUserQuestion tool)

Note that we only ask the LLM to attempt a reproduction and stop if too complicated. This sort of logic is very effective when working with agents since if we ask too much of them, they will often stumble. If we give them an out, they're more likely to explain the challenge than just stumble through it.

Example run on the Python issue

Continuing with the above Python example, the skill created this reproduction. We can see that it created a minimal Django app and gave very clear instructions to run the reproduction. Using this basic setup, I was able to roll out the subsequent fix very rapidly. I probably saved a few hours of figuring out how to setup Django with an HTTPS proxy correctly and then examining how that interacts with our SDK logic.

Lessons on writing skills

Skills are very generic Markdown files so it's a bit opaque how to make them reliable and avoid having them go off the rails.

Some insights I have from writing this one:

Use CLIs to interact with other systems; here we're using the gh CLI to perform GitHub operations
Split out the work to be done into clear steps
Add an Error Handling section explaining what's not allowed and what to do with bad inputs
Use other in-built tools such as AskUserQuestion for user input or validation

Full automation?

We will play around with fully automating this flow on GitHub issues in the future. A major concern voiced by several engineers here is increased bot noise. We're already drowning in bot communication on several fronts so we want to be careful how many of these we enable automatically. The right amount of automation in any given problem space is not always full automation and a pair of human eyes in the right places are absolutely necessary.

Errors, traces, logs, metrics: when to reach for what

Fri, 05 Jun 2026 09:00:00 GMT

When should I reach for a log, a trace, or a metric? I hit that question constantly when I instrument code, and I watch coding agents hit it too. It sounds like it should be obvious. Errors, traces, logs, and metrics are the four kinds of telemetry most apps run on, four tools in one box, and they overlap enough that the honest answer is every developer's favourite: it depends. You can stuff context into span attributes instead of logging it. You can count log events instead of emitting a metric. You can add a duration to a log and call it a span.

[I had a spiderman meme here but legal told me it would be infringing so I removed it]

But the fact that you can doesn't mean you should. Each signal exists because it answers a different question, and feeds a different workflow once it lands. Left without solid guidelines, the default is to reach for whatever's most familiar or already there, and miss what the other kinds are for.

This post is the guidance I wanted to have, for myself and my robots. Want just the skill? Skip to the end.

In Sentry, errors, traces, logs, and metrics all come from one SDK, included on every plan. Errors and tracing have been around for years (2012 and 2020), structured logs landed last year, and Application Metrics completed the set back in May of this year. If you've had your application instrumented with Sentry for a while, errors and traces are probably already flowing, with logs and metrics left as tools for you to complete your telemetry story.

Errors, traces, logs, metrics: one question each

Errors: "What just broke?"

A stack trace and an exception type, grouped into an Issue that gets deduplicated, assigned, and tracked until it's resolved. If your code threw an exception, it's an error.

Traces: "Did the request flow the way it was supposed to?"

A trace is a waterfall of timed spans. It's how you follow a request across your services and see where the time went: the DB query that dragged, the API call that timed out, the LLM tool call that took 8 seconds instead of 200ms.

Metrics: "How's this trending over time?"

Counters, gauges, and distributions, each kept as an individual measurement you can slice by any attribute and drill from an aggregate back into the samples (and the trace) behind it. Not just "12,000 checkouts this week," but 8,400 from the US, 2,600 from the EU, and 1,000 from everywhere else, and how that line moved across the last deploy. Metrics are a historical signal as much as a right-now one, which makes them an easy candidate for dashboards and alerts (but you can still set up alerts on pretty much all signals from Sentry).

Logs: "What was happening at this point in the code?"

The state of the system at one specific moment, captured as a structured event: config values, feature flags, the inputs and outputs of a function, the user ID. Logs are the trail through a function's decision tree: the markers you drop at the points where the code makes a choice, so that later, a human or an agent can follow the reasoning. They fill in the why once errors and traces have told you what broke and where the time went.

A real(ish) world example

Let's say you run a storefront with a React frontend and a Python API. Support starts forwarding tickets: the product recommendations on the account page look generic for a chunk of logged-in customers: bestsellers, not the personalized picks they're used to. The vibes are off.

Did anything crash?

First place I'd look is Issues. No exception in the React app, no failed request, every call to /recommendations/{user_id} came back 200. As far as error tracking is concerned, the app is perfectly healthy.

Was anything slow, or did the request go off-path?

Pull a trace for one of the affected requests. The route and the database queries are auto-instrumented; I added a few named spans for the recommendation steps:

The request loaded the user, evaluated the ranking_v2 flag, queried recommendations_v2, fell back to popular items, and ranked them. The path is right and the timing's fine. That recommendations_v2 query succeeded (returning zero rows is a perfectly successful query), so the code did what it was built to do and fell back. The trace tells me the request flowed as designed. It can't tell me the design just quietly failed this user. On the surface, everything is fine.

Can we dig a little deeper?

Search the logs for the user from the ticket, and the structured log from inside the handler will give you the state at the moment it decided to fall back.

This user got bucketed into the ranking_v2 feature flag, which reads personalized picks from a new recommendations_v2 table. The table shipped, but the rows were never backfilled, so the lookup came back empty. To the code, an empty result is a perfectly valid "no personalized recs for this user," the same thing a brand-new user with no history would get. So it falls back to bestsellers and returns 200.

Why not just attach this data on the span? You could set outcome and candidate_count as span attributes. But traces might be sampled, and the one request a customer is complaining about usually ends up being the one that's sampled out (at least with my luck). A span attribute is great for reading a trace you've found; it can't help you find one. Logs aren't sampled.

How many people hit it?

One affected customer is a support ticket. Knowing whether it's a small subset of users or a significant chunk is the difference between fixing it Monday and paging someone tonight. A recommendations.served counter, tagged with ranking_version and outcome, draws the line:

The v2 path is serving almost nothing but fallbacks, v1 is normal, and the drop lines up with the flag rollout. Scope and trigger, without opening a single trace.

No one signal cracked it; each ruled something out. No Issues in the feed meant it wasn't a crash. The metric said it wasn't a one-off: the whole v2 cohort was falling back. The trace, where one was sampled, showed the path running exactly as designed, which is why it slipped through. The log, pulled up by the user_id from the ticket, said why, and I never needed the trace to get to it.

When to reach for what

I use this as a gut check:

What you want to know	Reach for
Something crashed, show the stack trace	Errors
How long did this take? Which step is slow?	Traces
Did the request flow through the steps I expected?	Traces
What was the state when the code made this decision?	Logs
What did this function receive and return?	Logs
How often does X happen? Is the rate normal?	Metrics
Did something change after the deploy?	Metrics

The tricky cases are the overlaps, and of course there is nuance to all of this because the same value can show up in more than one signal.

Span attribute or metric?

If it's context about one request's flow through the system and you want it while reading that trace, it's a span attribute. It rides on the span in the waterfall. If it's a standalone value you want to chart, alert on, or slice over time across all requests, it's a metric. The same number can warrant both: candidate_count as a span attribute lets me read one request; recommendations.served as a metric lets me watch the rate. One is for inspecting a single flow, the other for watching the aggregate.

Log or span?

The span is the timed node in the flow, and most of them are auto-instrumented, so you rarely write them. The log is the decision-point state inside that node, and you always write it on purpose. Span answers where and how long; log answers what was true and why.

Log or metric?

A log is one request's story, the needle. A metric is the aggregate, the question of whether the haystack is normal. When you want to find the specific request that went wrong, that's a log. When you want to know how many requests went wrong, that's a metric.

Error or log?

If it needs a stack trace and should be tracked as an Issue, it's an error. If it's an unexpected-but-handled condition worth recording, it's a log. If it's truly non-critical, logger.warning(exc_info=True) captures the traceback in logs without creating noise in your error feed.

What the instrumentation looks like

Everything above came out of one endpoint: the GET /recommendations/{user_id} route from the walkthrough, the function that loads the user, checks the ranking_v2 flag, queries recommendations_v2, and falls back to popular items when it comes back empty. Here's that same handler with the instrumentation in place.

Most of it you don't write. The FastAPI integration traces the request, the database integration traces every query, so you get the path and the timing without a single hand-written span.

What you do place by hand are the deliberate signals: a span attribute or two to enrich the flow, the decision-point log, and the metric.


from sentry_sdk import logger

# The route is auto-instrumented. FastAPI gives you the request span;
# the DB integration gives you a span for every query below. You write none of it.
@app.get("/recommendations/{user_id}")
def get_recommendations(user_id: int):
    user = db.get_user(user_id)                          # auto-instrumented db span
    use_v2 = flag_enabled("ranking_v2", user)
    ranking_version = "v2" if use_v2 else "v1"

    candidates = db.personalized_recs(user_id, version=ranking_version)  # auto db span
    outcome = "personalized" if candidates else "fallback"
    items = candidates or db.popular_items()             # auto db span on the fallback

    # SPAN ATTRIBUTE: context about THIS request's flow, read inside the trace.
    # It rides on the auto-instrumented request span; no new span needed.
    span = sentry_sdk.get_current_span()
    span.set_data("ranking_version", ranking_version)
    span.set_data("recommendation.outcome", outcome)

    # LOG: the trail through the decision tree, the state at the moment the
    # code chose personalized vs. fallback. The only signal that records *why*.
    logger.info(
        "recommendations lookup",
        attributes={
            "user_id": user_id,
            "ranking_version": ranking_version,
            "flag.ranking_v2": use_v2,
            "source_table": f"recommendations_{ranking_version}",
            "candidate_count": len(candidates),
            "outcome": outcome,
        },
    )

    # METRIC: the rate across all requests, sliceable by version and outcome.
    sentry_sdk.metrics.count(
        "recommendations.served",
        1,
        attributes={"ranking_version": ranking_version, "outcome": outcome},
    )

    return items

Three deliberate touches, each carrying a piece the others can't. The span attribute tags the request's flow with the ranking path so it's right there when I open the trace. The log records what the function decided and why, at the instant it decided. The metric counts the outcome with enough dimension to slice it later.

If you do want a sub-operation timed in the waterfall (say the ranking step, or a call to an external recommender), you can wrap it in a custom span with sentry_sdk.start_span.

Beyond what you write, the SDK fills in even more on its own. Frontend SDKs tag everything with the browser, OS, and release. Call sentry_sdk.set_user() once and that user follows the errors, spans, logs, and metrics for the request. And because all four come from the same SDK, they share a trace_id and correlate on their own: every log carries the trace it belongs to, and you can jump from a metric spike straight into the traces behind it, without gluing four vendors together to get there.

All of this is ready for you to use and included in every plan. The deliberate signals (the span attributes, the decision-point logs, the metrics) are the ones you place yourself, and they only help if you do it ahead of time, at the spots where your code makes a decision worth questioning later.

Right tool for the job

The split above isn't just conceptual. It's baked into the APIs, and each one is tuned for its job. The Metrics API is built for emitting counts and measures you'll aggregate. The span API is built for measuring durations and the shape of a request. The log API integrates with your favourite structured logging library, so the lines you already write become queryable events. Reaching for the API that matches the workflow usually means reaching for the one that matches the kind of value you have: a count, a duration, or a moment.

Sampling falls out of the same logic. Traces are best as a sampled representation of your traffic: you don't need every request to understand where time goes, so a percentage is plenty (and cheaper). Logs are the opposite: you keep all of them, because the entire point is to find the one rare request that went sideways, and you can't find what you sampled away. Metrics aren't sampled either; like logs, you filter them with before_send_metric. Match the retention to the question: a representative sample for "where does time go," every single event for "what happened to this request."

You're not the only one debugging your codebase anymore

Cody from Modem instrumented his AI agent to find out where it was spending time. He worked with Codex to wrap the async work and the logical chunks (everything that runs before the call to the model, say) in spans. Cache hits and time-to-first-token became metrics he could watch over time. Values that only meant something next to a specific operation stayed as span attributes, and the lightweight "this happened here" markers became logs. The span-attribute-versus-metric call wasn't always obvious to him; his rule was that if a value only made sense in the context of a span, it lived on the span.

With the tracing in place, he pointed Codex at the Sentry data through the MCP server, feeding it real runs from his Playwright tests in development, and gave it one goal: optimize the code path. The agent read the spans, found work that could run in parallel, and rewrote the code to stop awaiting results until they were actually needed.

It could do that because a trace is a structured dependency tree with timing on every node, a format an agent can reason about directly. Hand it the same information as a stream of log lines and it would have to reconstruct the call graph from timestamps and string matching first.

But what about wide events?

There's a popular argument that the four signals are overkill: emit one rich, wide event per request and derive the rest later. It's half right.

Emit wide, absolutely. The best version of any signal is a structured event packed with context (the flag that was on, the user, the inputs and the outputs), not a bare number or a one-line string.

But the shape you emit is the shape you get to work with. One fat event in a columnar store charts fine after the fact, but it can't group itself into a deduplicated Issue, render itself as a waterfall, or fire a real-time alert on a threshold you haven't defined yet. Those are workflows, and each needs its data in a particular shape.

So emit wide, into the signal whose workflow you actually need. That's why the handler emits both a metric and a log: same decision, same trace, two shapes, because watching a rate and reconstructing one request are different jobs.

Getting started

Logs and metrics are the two you probably haven't turned on yet — they’re relatively new to Sentry, and people are still just finding them. Both are included on every plan.

You don't have to wire them up by hand. Point your coding agent at Sentry's setup skills for your stack and it installs the SDK, turns on tracing, logs, and metrics, and drops instrumentation at the decision points. Then aim it at your Sentry data through the MCP server and give it something real: your slowest trace, your newest issue.

Prefer to grab just the decision framework? It's a skill of its own:

npx skills add getsentry/sentry-for-ai --skill sentry-instrumentation-guide

The telemetry you emit to debug is the same telemetry it reads to help.

Want to go deeper on the logging side? Ben's follow-up post, When and what should I be logging?, covers what to log, how to structure your messages, and what to avoid.

How we cut build times by two-thirds by deleting our CMS

Thu, 28 May 2026 09:00:00 GMT

At Sentry, we're obsessed with things not breaking. It's kind of our whole deal. But for a while, our own marketing site was testing that obsession.

Much of what you see on sentry.io (the marketing site, blog, open source microsite, etc.) were running on a fleet of legacy Gatsby sites powered by a traditional headless CMS. On paper, it worked. In practice, we were juggling a fragile web of plugins, restrictive schemas, and external API dependencies that loved to fail right when we needed to ship.

So, we did what any sane engineering team would do: we ripped it out and replaced it with Astro, Markdown, and AI-driven automation.

The problem: the "headless" headache

Our old stack was starting to feel like a Rube Goldberg machine.

The build bottleneck: Gatsby's consolidated data layer was convenient, but as our content grew, our build times ballooned to ~14 minutes/build. At an average of 95 builds/day, this ended up being around 22 build hours used daily.
The CMS tax: We managed the content of ~2500 pages in a single CMS instance. We have different page schemas and connected component schemas without the ability to have conditional fields, so we ended up buying a conditional fields plugin to avoid hitting the schema limit. This made for an additional annual subscription on top of our monthly subscription, and scalability was still limited.
External fragility: Every build relied on external CMS and marketing automation system APIs via Gatsby plugins. During the last month before we started the rebuild, an issue with the CMS's Gatsby plugin would fail 3-5 times a day (to which there was no resolution, even after submitting a support ticket) and the marketing automation API would also fail multiple times a day due to rate limits (more on that below).

The solution: Astro and the power of "just files"

We migrated the framework to Astro. We chose it because it's built for the modern web — fast by default and incredibly flexible.

Vite-powered speed: Moving to Vite meant our local development and production builds finally felt like they belonged in 2026. We reduced our build times from ~14 minutes to less than 4 minutes, resulting in a savings of ~15.8 build hours daily.
Framework agnostic: Astro lets us use the best tool for the job. If a component works better in React, we use React. If it's a simple static partial, it's just HTML/CSS.
Vercel for the heavy lifting: We offloaded image processing to Vercel, ensuring our assets are optimized without dragging down the build process.

But the biggest shift wasn't the framework — it was how we handled content. We ditched the headless CMS UI for Markdown and Frontmatter.

AI-native content management (without the SaaS bloat)

Instead of paying for an "AI Add-on" from a CMS provider, we built a direct integration with Claude Skills.

Now, when someone needs to update the site, they don't log into a bloated dashboard. They use a skill-driven workflow that:

Guides the user through a process that precisely updates the Markdown files and Frontmatter directly.
Generates a live preview.
Drafts a Pull Request for review.

Why go custom instead of using a CMS-integrated AI?

Zero dependencies: Content lives in the repo. No API outages mean no failed builds.
Unlimited schemas: With Frontmatter, we define the structure. If we need a new field or schema type, we just add it. No subscription tiers, no restrictions.
The "Sentry" way: For a company with a developer-first culture that values the deeply technical, managing content as code feels right. It's version-controlled, peer-reviewed, and lives right next to the components that render it.

The process: how we did it

Moving a site with ~2500 pages between our marketing site and blog is a massive undertaking. We had a team of 2.5 developers and a two-month window to get it done.

Because of the small team size and large site volume, we relied on Claude Code for much of the coding. Our developers spent the bulk of their time on planning, scoping, and developing requirements, then reviewing the code, directing changes, and fine-tuning the output.

Scoping

This was easier for this project for 2 reasons:

We use a monorepo for these websites so the bots had the full context of what was being built and migrated
We did not implement any net-new design

Since we've been working in the existing codebase for over a few years, we had some ideas of where we could easily remove code bloat. We took a deeper look at the pages in certain directories to validate, and based on the content, eliminate bespoke pages with templates. As a result, we consolidated ~200 pages into 3 templates, making the site DRY and significantly easier to maintain.

Building with bots

We started with the data. Since our headless CMS was plugged into our Gatsby site and pre-existing parts of the Astro site, and our headless CMS provided JSON files of each schema available, we provided the planning agent with existing CMS schema and had it duplicated in Frontmatter. Since we were already connected to the CMS's API, we had an agent swarm pull down the data, map it to Frontmatter files, and pull down the images and save them locally as either an asset (for all non-meta image images needing image optimization) or in the public directory for SEO images.

Once the data was in place, we provided plan agents with the location of the existing template files in Gatsby, directions on where to place it in the new framework, what data it was using, and asked the agent to interview us on any missing information. From there, the planning agent would pass along the build tests to general purpose agents for the build, which was passed on to general purpose agents for testing.

After that round, our team would review & fix any regressions, which was followed with AI PR reviews using both Sentry's Seer AI code review tool and Cursor's Bugbot (along with other quality checks built into the repo, including secret scanning and our standard automated tests).

Testing with bots

As part of our development process, we experimented with Claude running visual regression tests with Playwright and a homegrown MCP we built to compare visual elements from our Gatsby site to the new Astro replacement.

The DOM-inspector MCP

Big shoutout to Dylan Coots on our team who built a DOM Inspector MCP that uses Puppeteer (headless Chrome) to connect to a locally running dev server and programmatically inspect, measure, and interact with elements on the page. It was designed to find UI layout issues like spacing shifts, element dimensions, and computed styles that can be passed along to a bot to fix.

Core Architecture

DOMInspector class — the central object that owns the Puppeteer browser/page lifecycle. It has two modes: a fully-owned browser (launched by the class) and a session-managed mode where an external page is passed in via the static fromPage() factory method.
Browser management — launches a headless Chrome instance with memory-constrained flags (--max-old-space-size=256, limited renderer processes) and handles graceful shutdown with a 5-second timeout before force-killing the process by PID if needed.
DOM inspection methods — includes inspectElement() (dimensions + computed CSS), measureDistance() (pixel/rem gap between two elements including which CSS property creates it), measureLayoutShift() (reloads the page and diffs element positions before/after a transition), and debugPage() (scans the DOM for common component patterns when a selector isn't found).
Interaction & navigation — interactWithElement() clicks a selector and measures before/after state; navigateToUrl() navigates to a new URL and clears stale console logs; setViewport() supports named presets (mobile/tablet/desktop/large) or any custom pixel width with auto-calculated height.
Utility methods — screenshot() (full page or scoped to a selector, returned as base64), evaluateJs() (runs arbitrary async JS in the page context), waitForSelector(), getPageContent() (text/HTML/outerHTML with truncation safety), and getConsoleLogs() (buffered, capped at 500 entries).
CLI entrypoint — main() only runs when the file is executed directly (not require()'d), accepts --url and --port flags, and runs a quick inspection of a hardcoded component (.WhoSentYouWrapper) as a smoke test.
extractUrlFromText() — a helper exported alongside the class for parsing localhost URLs out of natural-language strings, suggesting this is meant to be called from an MCP server that receives user text prompts.

What worked for us

The Playwright visual regression tests and the DOM Inspector MCP worked best together. Our visual testing workflow started with Playwright tests for each template to identify visual regressions. The results would be passed to another agent and fixes made. We followed it with the DOM Inspector MCP to fine tune elements that weren't fixed after the Playwright test fixes. We found the DOM Inspector to be more accurate with smaller, element-based inspections. Even then it wasn't 100%, but it did save us time on fixing tedious styling issues.

Updating content (also with bots)

Since updating content hurts in the CMS, we wanted to make it easy to update content without needing deep technical knowledge of Frontmatter or code in general, so we made some Claude skills for it.

Skills for the command line

For non-developers, understanding git operations (or even being in the terminal) can be intimidating. But, we saw the value of using a PR-based workflow for quality and consistency. So, we made some utility skills to help with this:

/new-branch — this would pull down the main branch on origin to prevent any avoidable merge conflicts, add a prefix to the branch name to know it came from a skill, and avoid any cruft from past branch checkouts from being included in the new PR.
/deploy-local-preview — since starting up a local dev server to preview your work takes a few lines in the terminal, we created a skill that does this for users. The skill will navigate to the site selected, spin up a dev server, and deploy a local preview.

Skills to update content

For each of our page types, we built skills that will create a Frontmatter file, ask the user for each field, upload images (with image size checks), call /deploy-local-preview to check the work, and use the Github CLI to create a pull request. This provides guardrails to make sure all the required information is given, reduces navigating a cumbersome CMS UI, prevents massive image files from being used (we added a polite reminder to compress to under 250kb and won't accept the larger file) and keeps page updates strictly to focus on content, not code.

Things to consider

Since we've built out skills with AI to update the content, there are a few things to keep in mind:

Compute is expensive. You don't need Opus to deploy a local preview when Haiku will do the job. We set default models on certain skills to make sure the model is right for the task. We also set the default model in the repo to Opus 4.6 to save on usage.
Use skills to catch large image files and other common things that will slow down performance. We added filesize limits to our page skills to prevent massive images from getting uploaded to our codebase and slowing down the build and site performance.
Protect sensitive parts of the site with Hooks. Since the models have access to the whole codebase and there are sensitive items you don't want changed, don't allow AI to change them. For example, we protected our Content Security Policy with a PreToolUse hook that prevents any changes to our CSP.

Fixing the "rate limit problem"

While we were under the hood, we tackled another recurring nightmare: API rate limits for our forms.

Our forms relied on fetching fields from our marketing automation system during the build. If we hit a rate limit, the build broke. To fix this, we built a service using Vercel Blob. We now fetch and store form fields in a fast, reliable blob store at the start of the build.

This reduced our marketing automation system API calls to nearly zero during the critical build phase, removing yet another point of failure.

The results: reliability as a feature

The shift from a heavy, API-dependent CMS to a lean, file-based Astro site has been a game-changer for our productivity.

Metric	Before (Gatsby + CMS)	After (Astro + Claude)
Average Build Time	14 Minutes	< 4 Minutes
Web Vitals Score	89	97
Broken Staging Builds	Frequent (API/Plugin issues)	95% Reduction
Content Schema Limits	Restricted by Plan	Unlimited
Vibe Check	Frustrating	High-Five Worthy

By moving our content into the codebase and using Claude to bridge the gap for non-technical users, we didn't just speed up our site — we made our entire deployment pipeline more resilient.

Because at the end of the day, the best way to fix a broken build is to remove the things that break it in the first place.

You don’t need to pick one: how Sentry and OpenTelemetry work together

Wed, 27 May 2026 00:00:00 GMT

You already instrumented the backend with OpenTelemetry. Your services emit spans. Your teams know the OTel APIs. Maybe you already run a Collector. So when you start evaluating Sentry, the obvious question is:

Do you need to replace your OpenTelemetry setup with the Sentry SDK?

No.

The practical answer is usually: keep OpenTelemetry where it already works, add the Sentry SDK where it gives you more application context, and send OpenTelemetry Protocol (OTLP) events to Sentry. For a web app, that often means using the Sentry SDK on the frontend for browser tracing, errors, logs, Session Replay, and source maps, while keeping OpenTelemetry on the backend for existing service instrumentation.

One scope note: OTLP can carry traces, logs, and metrics. At this moment, Sentry's OTLP ingest supports logs and traces, not metrics. We're considering adding support for them in the future.

The important part is separating two decisions that often get lumped together:

How traces stay connected across frontend and backend.
How backend OTLP events are exported to Sentry.

Once you separate those, the architecture gets a lot easier to reason about.

Sentry vs OpenTelemetry is the wrong question

The first decision is trace linking. If a user clicks a button in your React app and that click triggers a backend request, the frontend and backend need to agree on the same distributed trace context. In this example, the Sentry frontend SDK sends W3C traceparent headers (configurable through the propagateTraceparent option), and the OpenTelemetry backend continues the trace.

That linking is handled by the frontend SDK configuration:

Sentry.init({
  integrations: [
    Sentry.browserTracingIntegration(),
  ],
  tracesSampleRate: 1.0,
  // ensure traceparent headers get sent
  propagateTraceparent: true,
  tracePropagationTargets: [
    'localhost',
    '127.0.0.1',
    /^http:\/\/localhost:8000\/api\//,
    /^http:\/\/127\.0\.0\.1:8000\/api\//,
    // your backend endpoint here
  ],
})

The second decision is export. After your backend creates telemetry, where do those OTLP events go?

There are two common options:

Send OTLP events directly from the backend to Sentry's OTLP endpoint.
Send OTLP events to an OpenTelemetry Collector, then have the Collector forward them to Sentry's OTLP endpoint.

That trace-continuation step is what lets a Sentry-instrumented browser action become the parent of backend OpenTelemetry work, regardless of which OTLP export option you choose.

If you want the reference docs for these pieces, start with linking Sentry SDKs with OpenTelemetry SDKs, sending OpenTelemetry traces directly to Sentry, sending OpenTelemetry logs directly to Sentry, and forwarding OpenTelemetry data to Sentry.

Direct OTLP vs Collector forwarding

Direct OTLP and Collector forwarding both end at Sentry's OTLP endpoint. The difference is whether your service talks to Sentry itself or talks to a Collector first.

Approach	Use it when	What you get	Tradeoff
Direct OTLP to Sentry	You have one backend service or project and want the smallest setup	Fewer moving parts and a short path from service to Sentry	Less central control over processing, sampling, and routing
Collector forwarding	You have multiple services, already run a Collector, need processing, or want multi-vendor routing	Centralized routing, batching, processing, sampling, and easier vendor evaluation	Another component to deploy and operate

Direct OTLP is the simplest path for a single backend project:

Collector forwarding is the better fit when your observability setup is already more than one app talking to one destination. It gives you one place to receive telemetry from many services, batch it, process it, and send it to one or more backends.

That last part matters when you are evaluating Sentry. You can keep routing telemetry to an existing vendor while also forwarding a copy to Sentry, then compare the debugging experience without rewriting backend instrumentation.

There is one important Sentry-specific detail for larger setups: a generic OTLP HTTP exporter points at one Sentry project endpoint with one project key. If you send every service through that one exporter, every service lands in the same Sentry project. For multi-project routing, use the Sentry exporter. It can route OTLP events to projects based on a resource attribute like service.name, and it can auto-create missing projects when configured with the right Sentry API permissions.

A demo architecture

Let's check out a demo project that uses the Collector forwarding path:

React + @sentry/react
  -> fetch with traceparent
  -> FastAPI + OpenTelemetry
  -> OpenTelemetry Collector
  -> Sentry OTLP endpoint

The frontend lives in frontend/. It is a React + Vite app using @sentry/react. The backend lives in backend/. It is a FastAPI service using the OpenTelemetry SDK, FastAPI instrumentation, SQLAlchemy instrumentation, manual spans, and standard logging in checkout logic. The Collector lives in collector/ and forwards those OTLP events to Sentry.

The point of the demo is not that every layer uses the same SDK. The point is that every layer participates in the same trace, with backend logs attached to that debugging context.

The frontend uses the Sentry SDK

The Sentry setup is in frontend/src/instrument.ts. It enables browser tracing, Session Replay, logs, and trace propagation:

Sentry.init({
  dsn: import.meta.env.VITE_SENTRY_DSN || undefined,
  environment: import.meta.env.MODE,
  sendDefaultPii: true,
  integrations: [
    Sentry.browserTracingIntegration(),
    Sentry.replayIntegration({
      maskAllText: false,
      blockAllMedia: false,
    }),
  ],
  enableLogs: true,
  tracesSampleRate: 1.0,
  propagateTraceparent: true,
  tracePropagationTargets: [
    'localhost',
    '127.0.0.1',
    /^http:\/\/localhost:8000\/api\//,
    /^http:\/\/127\.0\.0\.1:8000\/api\//,
  ],
  replaysSessionSampleRate: 1.0,
  replaysOnErrorSampleRate: 1.0,
})

The frontend checkout flow is in frontend/src/hooks/useCheckoutLab.ts. It creates Sentry spans for user-facing work, logs useful state changes, and captures unexpected errors:

await Sentry.startSpan(
  {
    name: 'Run checkout scenario',
    op: 'ui.checkout',
    attributes: {
      scenario,
      itemCount,
      totalCents,
    },
  },
  async () => {
    const order = await createCheckout(cart, scenario)
    setLastOrder(order)
  },
)

The actual request is a normal fetch call:

const response = await fetch(`${API_BASE_URL}/api/checkout`, {
  method: 'POST',
  headers: { 'content-type': 'application/json' },
  body: JSON.stringify({ items, scenario }),
})

There is no manual trace header code in that request. The Sentry browser tracing integration handles the propagation as long as the destination matches tracePropagationTargets.

The backend keeps OpenTelemetry

The backend does not install or initialize the Sentry SDK. Its OpenTelemetry setup is in backend/app/core/observability.py.

It creates an OpenTelemetry TracerProvider, attaches service resource attributes, exports spans over OTLP HTTP, and registers W3C trace-context propagation:

resource = Resource.create(
    {
        **parse_resource_attributes(settings.otel_resource_attributes),
        "service.name": settings.otel_service_name,
        "deployment.environment": settings.app_environment,
    }
)
provider = TracerProvider(resource=resource)

if settings.otel_exporter_otlp_traces_endpoint:
    exporter = OTLPSpanExporter(endpoint=settings.otel_exporter_otlp_traces_endpoint)
    provider.add_span_processor(BatchSpanProcessor(exporter))

trace.set_tracer_provider(provider)
propagate.set_global_textmap(
    CompositePropagator(
        [
            TraceContextTextMapPropagator(),
            W3CBaggagePropagator(),
        ]
    )
)

It also configures OTLP log export. The backend creates a LoggerProvider, attaches an OTLPLogExporter, and adds an OpenTelemetry LoggingHandler to the app logger:

provider = LoggerProvider(resource=build_resource(settings))
exporter = OTLPLogExporter(endpoint=settings.otel_exporter_otlp_logs_endpoint)
provider.add_log_record_processor(BatchLogRecordProcessor(exporter))
set_logger_provider(provider)

otel_handler = LoggingHandler(level=logging.INFO, logger_provider=provider)
app_logger = logging.getLogger("checkout_trace_lab")
app_logger.addHandler(otel_handler)
app_logger.setLevel(logging.INFO)

The default backend endpoints are local:

OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://localhost:4318/v1/traces
OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=http://localhost:4318/v1/logs

That means the backend exports OTLP traces and logs to the Collector, not directly to Sentry.

The FastAPI app also allows the browser trace headers through CORS:

allow_headers=[
    "content-type",
    "sentry-trace",
    "baggage",
    "traceparent",
    "tracestate",
]

This is easy to miss. If your browser is making cross-origin requests and CORS blocks the propagation headers, your frontend and backend traces can split apart even if both sides are instrumented correctly.

The checkout flow adds manual OTel spans and logs

The backend service code in backend/app/services/checkout.py models a checkout workflow. It creates manual OpenTelemetry spans for business operations:

def validate_cart(engine: Engine, payload: CheckoutRequest) -> dict[str, ProductRow]:
    with tracer.start_as_current_span("checkout.validate_cart") as span:
        requested_ids = [item.product_id for item in payload.items]
        span.set_attribute("cart.item_count", len(payload.items))
        ...

The checkout path includes spans for:

checkout.validate_cart
checkout.reserve_inventory
checkout.calculate_tax
checkout.payment
checkout.write_order
checkout.send_confirmation

It also emits backend logs for the same business steps, such as checkout.started, checkout.cart_validated, checkout.inventory_reserved, checkout.payment_approved, checkout.order_written, and checkout.completed. Those logs go through Python's standard logging API, then the OpenTelemetry LoggingHandler exports them through OTLP.

This is the part OTel-first teams care about most. Those spans and logs stay in the OpenTelemetry pipeline. You do not need to rewrite them with Sentry.startSpan() or Sentry logging APIs just to view the trace and related logs in Sentry.

The Collector forwards OTLP to Sentry

The Collector config is in collector/otel-collector.yaml. It receives OTLP over gRPC and HTTP:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

It batches the data:

processors:
  batch:
    send_batch_size: 1024

Then it forwards to Sentry with the OTLP HTTP exporter:

exporters:
  debug:
    verbosity: basic
  otlphttp/sentry:
    endpoint: ${env:SENTRY_OTLP_ENDPOINT}
    headers:
      x-sentry-auth: "sentry sentry_key=${env:SENTRY_OTLP_PUBLIC_KEY}"
    compression: gzip
    encoding: proto

Reminder: this demo uses generic otlphttp for a single Sentry project. For multi-project routing or automatic project creation, swap it for the sentry exporter.

The configured pipelines send to both the debug exporter and Sentry:

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug, otlphttp/sentry]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [debug, otlphttp/sentry]

That is the Collector forwarding pattern: the backend sends OTLP events to one local endpoint, and the Collector decides where that telemetry goes next.

What each layer is responsible for

The cleanest way to understand this architecture is by ownership.

The frontend Sentry SDK owns browser-specific debugging context:

Browser spans and frontend transactions
Frontend errors and React error boundaries
Session Replay
Frontend logs
Source maps through the Sentry Vite plugin
Trace propagation to the backend

The backend OpenTelemetry SDK owns backend instrumentation:

FastAPI request spans
SQLAlchemy spans
HTTPX spans if the backend calls other services
Manual checkout spans
Backend logs exported with OpenTelemetry
Resource attributes such as service.name and deployment.environment
OTLP export to the Collector

The Collector owns routing and processing:

Receiving OTLP on 4317 and 4318
Batching telemetry
Printing debug output locally
Forwarding to Sentry's OTLP endpoint
Providing the place to add sampling, transforms, filters, or multi-vendor routing later

This is why Sentry and OpenTelemetry are not competing choices here. They are doing different jobs in the same observability pipeline.

What you can see in Sentry

In the demo, I ran the checkout scenarios from the same frontend session. In Sentry, they show up as one connected trace that starts in React and continues through the FastAPI backend. You can see the normal checkout, slow payment, inventory miss, payment declined, and backend crash work in the same distributed trace instead of jumping between separate tools.

The backend logs are associated with that trace too. Logs like checkout.started, checkout.inventory_reserved, checkout.payment_slow_path, and checkout.completed come from Python's standard logging API, get exported through OTLP, and land in Sentry attached to the same debugging context as the spans.

That is the useful part of the setup: the frontend SDK gives you browser context, the backend keeps its OpenTelemetry spans and logs, and Sentry gives you one place to inspect the full request path.

A decision tree for your own app

Use direct OTLP to Sentry when:

You have one backend service or one project.
You want the fewest moving parts.
You do not need central processing or multi-destination routing yet.

Use Collector forwarding when:

You already run an OpenTelemetry Collector.
You have multiple backend services.
You need services to land in separate Sentry projects.
You need sampling, filtering, transforms, or batching outside the app process.
You want to send telemetry to Sentry and another vendor while evaluating Sentry.

Add the Sentry backend SDK later when:

You need error monitoring. OpenTelemetry does not capture and send errors to Sentry—only the Sentry SDK can capture backend exceptions and link them to the trace, so you can jump from an error to the full request path and inspect the related logs, spans, and context.
You want profiling.
You want Sentry's Application Metrics.
You want other Sentry features that are not represented by your current OpenTelemetry data.

That last step is optional, not a prerequisite. You can start with Sentry on the frontend and OpenTelemetry on the backend, then decide later whether adding the backend Sentry SDK is worth it for your services.

Start with the smallest change that preserves your trace

If your backend already uses OpenTelemetry, do not start by rewriting instrumentation. Start by deciding where OTLP events should go.

For a single backend, direct OTLP to Sentry is usually enough.

For multiple services, vendor evaluation, or anything that needs routing and processing, put a Collector in the middle.

Then link your frontend Sentry SDK to your backend OTel SDK with W3C traceparent propagation. That gives you the useful part first: one trace that starts where the user action starts and continues through the backend code you already instrumented.

You do not need to pick Sentry or OpenTelemetry. Use both where they fit.

Your agent can't fix what it can't see

Tue, 26 May 2026 16:00:00 GMT

Agents are getting better and better at fixing bugs. They're even getting better at testing their work, thanks to headless browsers, sandboxes, simulators, etc.

But what about the bugs that only show up once you bring in different browsers, languages, extensions, internet speeds, and all the other variables that get mixed in the second you ship to prod? Or all the bugs that only show up when you account for… well, humans being humans and doing weird stuff you didn't expect them to do?

The bottleneck for self-healing software isn't agent intelligence. It's that agents have no idea what actually broke. They're debugging from source code alone, which is roughly as effective as diagnosing a server outage by skimming the README. What they're missing is production context: the stack trace, the request payload, the environment, the breadcrumbs leading up to the failure.

Your agents need someone/something telling them what's breaking in the wild and giving them the context they need to understand why.

We built Sentry MCP and the Sentry CLI to make that context available to both humans, and increasingly as important, their agents. You can wire up a system today where a Sentry alert triggers an agent, the agent investigates the issue using the same evidence you would, and a draft PR with a fix lands in your repo before you open a browser.

Why draft PRs, not auto-merge

Let's be honest about what's realistic. A system that detects, fixes, tests, deploys, and monitors its own patches without human involvement is not something you should build today. That's how you get a very exciting incident review.

The useful version is more modest: a production error fires, an agent investigates it with real Sentry context, writes a small fix with a regression test, and opens a draft PR. A human is very much in the loop.

That's not fully autonomous, but it's not trivial either. Most bugs sit in a queue, triaged, prioritized, assigned, waiting, and often lose out to new features. Seer diagnoses the root cause in under two minutes. A complete Autofix run, from root cause analysis to an opened PR, takes about six minutes.

An agent that opens a reviewable, mergeable fix six minutes after the error fires is a meaningful change to your mean time to resolution, even if a human still clicks merge.

Two ways to give your agent production context

Sentry MCP is the right choice for agents that support the Model Context Protocol (Claude Code, Cursor, Codex, Windsurf, VS Code with Copilot). Your agent connects to the hosted server, authenticates via OAuth, and gets structured access to issues, events, traces, and Seer analysis. No local install required.

# One-liner for any MCP-compatible client
npx add-mcp https://mcp.sentry.dev/mcp

# Or for Claude Code specifically
claude mcp add --transport http sentry https://mcp.sentry.dev/mcp

If your client doesn't support the one-liner, add the config manually:

{
  "mcpServers": {
    "sentry": {
      "url": "https://mcp.sentry.dev/mcp"
    }
  }
}

The Sentry CLI is the right choice for scripted workflows, CI pipelines, or any automation where you need structured output you can pipe to jq or feed into another process.

curl https://cli.sentry.dev/install -fsS | bash
sentry auth login

Here's what that looks like:

$ sentry issue list

Issues in acme/checkout:
╭──────────────┬──────────────────────────────────────────────────────┬──────┬─────┬────────┬───────┬──────────────╮
│ SHORT ID     │ ISSUE                                                │ SEEN │ AGE │ EVENTS │ USERS │ TRIAGE       │
├──────────────┼──────────────────────────────────────────────────────┼──────┼─────┼────────┼───────┼──────────────┤
│ CHECKOUT-P1  │ TimeoutError: Payment charge exceeded 30s            │   3h │  3h │  1.8k  │   340 │ High  86%    │
├──────────────┼──────────────────────────────────────────────────────┼──────┼─────┼────────┼───────┼──────────────┤
│ CHECKOUT-N7  │ TypeError: Cannot read property 'total'              │   1d │  5d │    215 │    82 │ High  71%    │
├──────────────┼──────────────────────────────────────────────────────┼──────┼─────┼────────┼───────┼──────────────┤
│ API-34       │ RateLimitError: Too many requests to /v1/charges     │   3d │ 21d │     67 │    24 │ Med   42%    │
╰──────────────┴──────────────────────────────────────────────────────┴──────┴─────┴────────┴───────┴──────────────╯
Tip: Use 'sentry issue view ' to view details.

CHECKOUT-P1 is at the top, a timeout in the checkout service with 1.8k events and an 86% fixability score. Drill in:

$ sentry issue view CHECKOUT-P1

CHECKOUT-P1: TimeoutError: Payment charge exceeded 30s
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
╭────────────┬─────────────────────────────────────────────╮
│ Status     │ ● Unresolved (Ongoing)                      │
│ Fixability │ High (86%)                                  │
│ Level      │ error                                       │
│ Platform   │ node                                        │
│ Project    │ checkout-service                            │
│ Events     │ 1832                                        │
│ Users      │ 340                                         │
│ First seen │ 3 hours ago                                 │
│ Last seen  │ 12 minutes ago                              │
│ Culprit    │ chargeCustomer (src/payment.ts)             │
│ Link       │ https://acme.sentry.io/issues/CHECKOUT-P1/  │
╰────────────┴─────────────────────────────────────────────╯

Tip: Use 'sentry issue explain CHECKOUT-P1' for AI root cause analysis

Looks like a straightforward timeout. An agent with just this would add retry logic or bump the timeout. But run sentry issue explain:

$ sentry issue explain CHECKOUT-P1

ℹ Starting root cause analysis, it can take several minutes...

Root Cause Analysis Complete
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Cause #0: The checkout service's /charge endpoint times out
waiting for the payment service, which blocks on an inventory
availability check. The inventory service's check_stock query
regressed from ~200ms to ~28s after migration
0047_drop_unused_indexes removed the compound index on
(product_id, warehouse_id).

Repository: acme/inventory-service
Affected: src/queries/check_stock.ts:18
First seen: release-3.1.0 (deployed 3h ago)

Reproduction steps:
1. User submits checkout → POST /charge
2. Payment service calls inventory.check_stock(items)
3. check_stock runs full table scan (missing index) → 28s
4. Payment call exceeds 30s timeout → TimeoutError bubbles up to checkout

To create a plan, run: sentry issue plan CHECKOUT-P1

The root cause isn't in the checkout service at all. It's a dropped database index in the inventory service, two hops away in the trace. No amount of retry logic in payment.ts fixes that.

From alert to draft PR

When a Sentry alert fires on a new or regressed issue, a webhook triggers a worker that checks out your repo and runs a coding agent with a prompt grounded in the specific issue:

A production error was captured by Sentry. The issue ID is CHECKOUT-P1.

Use Sentry MCP to retrieve the full issue details: stack trace,
breadcrumbs, tags, release, environment, distributed traces,
suspect commits, and Seer analysis.

Based on the evidence:

1. Identify the root cause. Follow traces across services.
2. Make the smallest safe fix in the right repository.
3. Add or update a regression test that covers this failure.
4. Run the test suite.
5. Open a draft PR with the Sentry issue link, root-cause
   summary, files changed, and test results.

The agent pulls the issue via MCP. The distributed trace shows the checkout call chaining through the payment service into an inventory check that's taking 28 seconds. Metrics confirm the inventory service's p99 spiked from 200ms to 28s three hours ago. Suspect commits point at a migration in acme/inventory-service that dropped a compound index. Session replay shows users rage-clicking "Pay" while nothing happens, generating duplicate charge attempts.

sentry issue plan CHECKOUT-P1 lays out the fix: restore the compound index on (product_id, warehouse_id). A draft PR lands in acme/inventory-service with the migration, a root-cause summary linking back to the Sentry trace, and a regression test.

Try it with Cursor Automations

We publish a cookbook recipe for this exact workflow using Cursor's Automations feature. It walks through connecting your repo to Sentry, adding the MCP server to an automation, and configuring a webhook alert to trigger on regressed issues.

Because Sentry knows the release history and suspect commits, the agent doesn't search the entire repo for the problem. It starts where the evidence points. For regressed issues specifically, it can identify which commit reintroduced the bug, read the original fix, and understand what went wrong the second time around.

What's next

The more telemetry your app sends to Sentry (traces, metrics, logs, session replays), the harder the bugs an agent can tackle. Today it's dropped indexes across service boundaries. Six months ago it was null checks. The merge rate on Autofix PRs has climbed from 41% to 46% in that time, and the diagnosis complexity is growing with it.

There are real limits. Bugs that need product judgment, issues in code the agent can't reach, and problems where there isn't enough telemetry to connect the dots: those still need you. But the surface area of what agents can fix is expanding every month.

Connect Sentry MCP to your editor or install the CLI. Hook up your repos for code mappings and tracing. Run sentry issue explain on something that's been sitting in your backlog and see what it finds.

Check out the Seer Autofix docs for more on coding agent handoff to Claude Code and Cursor.

The product analytics you already have

Thu, 21 May 2026 09:00:00 GMT

You already have everything you need.

If you're using Sentry, you have traces, structured logs, and now application metrics. Most teams use that stuff for debugging and stop there. But get this: that same data can answer most of the product questions you've been sending to a separate analytics tool, maintained by a separate team, with a separate data model and a separate bill. (Not all of them. We'll get honest about the gaps later.)

This isn't a post about whether product analytics tools should exist. It's about the fact that developers have been sitting on top of a goldmine of product insight and outsourcing the questions to someone else. You don't have to.

There's a reason this matters more now than it did five years ago. The line between "product manager" and "software engineer" is blurring. Engineers are increasingly expected to think about adoption, retention, and user behavior, not just uptime and latency. If you're a product engineer (and increasingly, that's just "engineer"), the tools you already use for debugging are the same tools you should be using to answer product questions. You just haven't been querying them that way.

Every product question maps to telemetry you already have

"How many users completed onboarding this week?" That's a counter metric: metrics.count("onboarding.completed", 1). You can slice it by plan tier, country, or referral source with attributes you're already setting.

"What's our p95 checkout latency by region?" That's a distribution on a span. The trace already has the timing. You just need to query it.

"Why did signups drop on Tuesday?" That's a structured log. The signup service logged signup.failed with reason: email_validation_error and deploy_sha: a3f9b2c. The log is already correlated to the trace that shows the full request lifecycle, the span that errored, and the release that introduced it. From the trace, you're one click away from the issue, which links you to the commit and the line of code that caused it.

These are the same questions your PM asks their analytics tool. The difference is that when you answer them from your telemetry, the answer comes with context. The analytics tool gives you the "what." Your telemetry gives you the "what," the "why," and a direct path to the code that's responsible.

A customer told us recently that they were tired of analytics tools giving them a heads-up after the damage was done. They wanted to be proactive. The way they got there was setting up alerts and monitors on the telemetry they were already collecting. When a business-critical metric starts trending down, the alert fires before the weekly dashboard review catches it. And because the alert is on a span or a metric that's connected to the full trace, the investigation starts with context, not a context-switch to a different tool. They didn't change the data they were collecting. They changed how they were watching it.

What it looks like in practice

Say you want to know whether users are adopting your new export feature, whether it's performant, and whether paid users behave differently than free users.

You don't need to file a ticket asking someone to instrument this in an analytics tool. You already have the three primitives: spans, logs, and application metrics.

Spans for request-level context. Spans tell you how requests move through your system and how long each operation takes. The export API handler already has a span. Add business-level attributes (like export.user_tier, which lets you slice by plan):

with sentry_sdk.start_span(op="export.generate", name="Generate export file") as span:
    span.set_attribute("export.file_size_mb", file_size_mb)
    span.set_attribute("export.format", export_format)
    span.set_attribute("export.user_tier", user.plan)
    span.set_attribute("export.row_count", row_count)

Query adoption, performance, and errors in one place:

span.op:export.generate | count(), avg(span.duration), count_if(span.status:internal_error)
  group by export.user_tier, export.format

export.user_tier  | export.format | count() | avg(span.duration) | error_count
──────────────────|───────────────|─────────|────────────────────|────────────
pro               | xlsx          | 1,204   | 3.8s               | 89
pro               | csv           | 3,847   | 1.2s               | 24
free              | csv           | 12,493  | 0.9s               | 3
free              | xlsx          | 891     | 4.1s               | 142

You can already see the story: xlsx exports are 3-4x slower than csv, and free-tier xlsx is erroring on 16% of requests. You didn't need an analytics tool to surface that. You needed to query the spans you already had.

Structured logs for discrete business events. Logs capture discrete events with enough detail to help you debug what happened and why. When a user upgrades their plan, you want to record the events that took place before and after the plan change, where it was triggered, and any revenue impact. That's a business event worth recording, but it's not a performance-sensitive operation you need to trace end-to-end. Log it:



sentry_sdk.logger.info(
    "plan.upgraded",
    previous_plan=previous_plan,
    new_plan=new_plan,
    user_id=user.id,
    upgrade_source=source,  # "paywall", "settings", "checkout"
    mrr_delta_usd=mrr_change,
)

Now you can query plan upgrades by source, see which upgrade path drives the most revenue, and if something breaks in the upgrade flow, the log entry is already linked to the trace context that shows you where it failed.

Query your logs for upgrade events from the past 30 days:

plan.upgraded | count(), sum(mrr_delta_usd)
  group by upgrade_source

upgrade_source | count() | sum(mrr_delta_usd)
───────────────|─────────|───────────────────
paywall        | 842     | $27,340
settings       | 214     | $8,120
checkout       | 1,307   | $51,890

Checkout drives the most upgrades, but it also converts at a higher average MRR per upgrade ($39.69 vs. $32.47 for paywall). That's the kind of insight your PM is running a separate tool to get, and it's sitting in your logs.

Application Metrics for KPIs and health signals. Metrics are how you track the measures that tell you whether things are healthy – both in your service and your business. Things like checkout conversion rate, signup and traffic over time, and error budget burn. These are the signals you track continuously, get alerted on, and study trends:

from sentry_sdk import metrics

metrics.count("export.completed", 1, attributes={"tier": user.plan, "format": export_format})
metrics.distribution("export.file_size", file_size_mb, attributes={"tier": user.plan})

This gives you a counter and distribution you can alert on, visualize, and use to observe trends over time without building or maintaining an analytics pipeline.

That's three primitives in one SDK covering every angle you need: request-level detail from spans, discrete business events from logs, and aggregated trends from metrics, all queryable in one tool and all connected to each other.

Compare this to the usual workflow: someone instruments a feature_export_used event in an analytics tool, builds a dashboard, checks it weekly. Three weeks later they notice adoption is flat. They ask engineering if there are issues. Engineering checks Sentry, finds the export is timing out for files over 50MB, which covers most real-world usage. Three weeks lost because the analytics tool could see the symptom but not the cause.

With your telemetry, you can set up a monitor on that span's error rate and duration. When the timeout starts happening, the alert fires on the span itself, not on a downstream analytics metric that takes weeks to reflect the problem. The metric shows the count dropping. The span shows the duration spiking. The log shows the error. And all three point back to the same trace, the same release, the same line of code.

To go one step further, you can ask Seer if anything is broken that may be causing adoption to stay flat.

The skills already transfer

If you're already using Sentry for debugging, the only mental shift is realizing that "business telemetry" and "system telemetry" aren't different categories.

The business question ("did the user convert?") and the engineering question ("did the request succeed?") are the same question asked at different altitudes. You don't need a separate tool to ask the business question. You need to add purchase.value_usd to the span you already have, log the purchase.completed event with the attributes that matter, and increment the counter.

# On the span
span.set_data("purchase.value_usd", order.total)
span.set_data("purchase.item_count", len(order.items))

# As a structured log
sentry_sdk.logger.info(
    "purchase.completed",
    value_usd=order.total,
    item_count=len(order.items),
    coupon_applied=bool(order.coupon),
    user_id=user.id,
)

# As a metric
metrics.count("purchase.completed", 1, attributes={"coupon": str(bool(order.coupon))})
metrics.distribution("purchase.value", order.total, attributes={"plan": user.plan})

One customer framed it well: when there's a discrepancy in a business metric, it shows up in other parts of the system too. That's what observability means. Everything is connected. The moment you start treating your telemetry as the source of truth for product questions, you stop needing a second system to answer them.

Where this gets hard (and why it's getting easier)

Let's be honest about the gaps.

Multi-session retention analysis, behavioral cohorts ("users who did X but not Y within 14 days"), and cross-session funnel conversion are genuinely difficult to reconstruct from raw telemetry. Spans are request-scoped. Logs are event-scoped. Metrics are time-series. Stitching together a user's journey across sessions and days requires aggregation infrastructure that observability tools haven't traditionally built.

If your PM needs a 30-day retention curve segmented by acquisition channel, you can't just GROUP BY your way there today.

But most of the data is already there. Your spans, logs, and metrics all carry user IDs, timestamps, and business attributes. The missing piece is the aggregation and visualization layer. That's a query engine problem, not a data model problem. OpenTelemetry is making this easier to solve every quarter, because once instrumentation is standardized, the aggregation layer becomes commoditized. The gap is real, and it's shrinking.

We think there's interesting work to be done here, and we plan to dig into some of these harder use cases in future posts, showing how far you can get with Sentry's existing query tools even for cross-session analysis.

For the questions that matter day-to-day as a developer building and shipping features, the gap doesn't exist. Is my feature being adopted? Is it performant? Is it erroring? Are paid users behaving differently than free users? Which upgrade path drives the most revenue? You can answer all of these right now, from the telemetry you already have, without waiting for anyone.

Try it

Pick one feature you shipped recently that you're curious about. There most certainly is an opportunity to:

Add business-level attributes to the spans on the critical path of that feature's functionality
Add Sentry Logs that are high cardinality wide events including details you would want to query this data by (user plan, surface, activity data)
Sprinkle application metrics across with attributes that will be useful in creating dashboards.

We have found that agents are quite good at following these types of requests, and we have some skills to deploy in your local IDE and once you're done, ask Seer Agent about the best ways to create dashboards, monitors and alerts for them.

See how long it takes before the analytics dashboard for that feature stops being the thing anyone opens first.

You already have the data, you already have the tools, and you've just been letting someone else ask your questions for you.

New ways to agentically build and edit dashboards

Thu, 14 May 2026 09:00:00 GMT

The traditional dashboard workflow, teams slowly handcrafting visualizations to track critical KPIs, is dying in a world of AI agents.

A few years ago, in a pre-agentic-everything world, we tried to make it easier for developers to monitor critical experiences. We introduced Insights pages, which were pre-configured dashboards any Sentry user could adopt instantly that surfaced common health signals, like Web and Mobile Vitals.

The idea was right, but there was a problem: while many companies share common signals, every organization is unique. Without meaningful customization, most teams still ended up having to slog through manually building dashboards themselves. So we kept iterating.

Large language models are what finally made a reality of on-demand, customizable dashboards possible. Visualizations remain one of the most information-dense ways for humans (and agents) to communicate. What changed is the cost of creating those views.

Instead of assembling dashboards widget by widget, you can now prompt an agent to create or edit dashboards directly in Sentry, or use the Sentry CLI to connect Sentry to other models, and generate a dashboard tailored to the task at hand.

Insights pages are now Sentry-built Dashboards. Clone them, then ask an agent to customize them for your project. Dashboards can now be created in seconds, used for the lifetime of a project or investigation, and discarded once they stop providing value.

What's new

Agentic dashboard creation & editing (beta): All organizations with AI-powered features enabled can now create and edit dashboards in Sentry using an agent-powered chat experience.
Insights are now Sentry dashboards: We replaced Insights pages with clonable, editable Sentry dashboards that you can customize to fit your specific use case.
Dashboard creation & editing via the Sentry CLI: You can create and manage Sentry dashboards from your terminal via the all-new Sentry CLI.

Note: Sentry dashboards use issue, tracing and application metrics data. You can also query against multiple event types in Sentry and save queries to dashboards.

Agentic dashboard generation and editing

You can now create and edit dashboards in Sentry agentically via the same capabilities that power Seer, Sentry's AI debugger (Note: while Seer is an add-on option, agentic dashboard creation is a separate feature that is available for free). When you create or edit a dashboard, you still have the option to add or edit manually, but you can now just tell Sentry what you want and we'll put it together for you automatically. Creating and editing dashboards with AI makes the experience of going from concept to final dashboard much faster than manual creation:

It's a best practice to use agentic dashboard creation as a starting point for a new dash or edits to an existing dash, and then verify and tweak the updates to make sure it's exactly what you want. This experience is still in open beta, so we're still ironing out some of the kinks.

Many more dashboards can now easily be created. With this in mind, we've created a markdown widget to encourage you to leave notes and document what you've built:

Dashboard revision history

Dashboards now maintain a revision history. Any edits made through the UI, Seer agent, or API are automatically tracked. To view prior revisions, click the clock icon in the upper-right corner.

If you, or a 🤖, make a mistake, you can restore a known-good version by selecting a previous revision and clicking Revert to Selection.

Sentry use case: fixing and monitoring jest tests

Last week, we increased the number of CI runners we use for jest tests, moving from 4 to 8 on our main branch. We've had 4 runners for years to parallelize the work. Total CI time depends on how long the slowest runner takes to do its work; to make sure that everything finishes at the same time we measure the duration to run each test file and parallelize based on that. More runners should mean faster CI time.

Instead, we noticed that overall CI time had been regressing for a few days, going from 6 minutes up to 10. The culprit was that the balancer script wasn't running successfully because tests were failing out. Once we fixed some flaky tests, that time went down from ~10 minutes to less than 4. Our new runner configuration did improve overall CI time after all!

To prevent this from happening again we used agentic dashboard creation (plus some manual metric creation) to whip up some new dashboards (and monitors) to keep tabs on flakes, balance failures, and overall slowness:

Insights are now Sentry dashboards

In the Dashboard nav item, you'll see the option to explore Sentry Built dashboards:

This is a collection of dashboards pre-built by Sentry to address common monitoring use cases. The Sentry-built dashboards cannot be edited, but they can be duplicated to create custom dashboards. You can think of them as templates that can be adapted to address your specific use case.

On the frontend side, the Web Vitals dashboard surfaces LCP, INP, CLS, and TTFB across your real users, broken down by page, with a Performance Score that flags which pages have the most room to improve. Frontend Session Health connects deployments to crash and error rates, so you can see when a release tanked your stability. Frontend Assets shows you which JS and CSS assets are slow or render-blocking, useful when LCP regressed and you don't yet know why.

On the backend side, you get dashboards for slow queries (with drill-downs into individual query summaries and sample events), cache hit/miss rates, queue throughput and processing latency, and outbound API requests grouped by domain. The Backend Overview ties these together with p50/p75 duration and the most time-consuming queries and domains.

For mobile, there's Mobile Vitals (cold/warm app starts, slow and frozen frame rates, TTID/TTFD), Mobile Session Health (crash-free sessions and users, with release annotations), and dedicated drill-downs for app starts and screen rendering.

There are also framework-specific dashboards: a Next.js Overview with a tree-based SSR view for finding performance bottlenecks, and a Laravel Overview tuned for Laravel-specific metrics.

Creating dashboards via the Sentry CLI

The Sentry CLI includes a full dashboard command, bringing dashboard creation and management out of the browser and into your shell. You can list, view, create, and modify dashboards, including adding, editing, and deleting individual widgets, without ever leaving your terminal. With the new dashboard command, dashboards become code-adjacent artifacts: scriptable, repeatable, and reviewable. Define dashboards in shell scripts or CI pipelines, commit them alongside your application code, and roll them out the same way you ship features.

Every command supports --json output, making it straightforward for scripts, internal tools, or AI coding agents to provision and update dashboards programmatically (that means you can easily create dashboards from Claude Code, GitHub Copilot, Cursor, or your agent of choice).

Sentry use case: investigating integrations

In order to test out a potential yabeda integration for application metrics, one of our engineers created a custom dashboard with the CLI and documented the process.

Get started

Whether you're cloning a Sentry-built dashboard as a starting point, prompting an agent to spin one up from scratch, or scripting dashboard creation directly from your terminal, the goal is the same: spend less time building the view and more time acting on what it shows you:

Sentry Dashboards are available now on all plans. Open Dashboards to see them.
Custom Dashboards are available on all plans. Click Create Dashboard to start from scratch, or duplicate a pre-built dashboard.
Agentic Dashboard creation is live now for organizations with AI features enabled. If you don't see the Generate Dashboard option, check your org's AI settings.

Have questions or feedback?

Join the conversation in our Discord

New to Sentry?

Try Sentry for free

From vibe code to production-ready: observability for Next.js and Supabase apps

Mon, 11 May 2026 09:00:00 GMT

The way we build software has drastically changed over the past few years. What hasn't changed is that this software ends up in front of real people: you, me, my mom.

And when those users inevitably run into something broken, you as the application's developer need to be equipped with the right tools, context and understanding of what broke, where it broke, and how to fix it as quickly as possible.

Every day we're inching closer to self-healing software. If you are building a Next.js application and are using Supabase as the backend service, the tooling described below can help you get one step closer to a self-closing loop of producing quality software and fixing what slipped through the cracks with minimal disruption.

TL;DR

Supabase gives you query performance insights, row-level security (RLS) advisories, and edge function logs out of the box, but it can't trace across your full stack
Sentry fills that gap: distributed traces from your Next.js frontend through Supabase Edge Functions to Postgres, all in one place
Log draining from Supabase into Sentry gives you a single source of truth for errors, traces, and infrastructure logs
Sentry auto-detects N+1 queries, slow spans, and performance regressions without manual configuration
Seer, Sentry's AI debugger, can suggest a likely root cause for new issues automatically and hand off fixes to your coding agent

The stack problem agents create

AI-assisted development has a specific failure mode: agents write working code that has no observability built in. You could end up with a Next.js app that talks to Supabase via three different connection methods (direct Postgres, the Supabase JS SDK, and Drizzle, because the agent kept switching strategies), edge functions running in Deno, and no unified view of what's actually happening at runtime.

The other failure mode is subtler. Agents forget indexes. They could end up writing N+1 queries that are invisible locally because your dev database has 40 rows. You ship, your database grows to 400 rows, and suddenly a search query takes ten seconds. Sentry catches this automatically, but only if it's instrumented correctly from the start.

Getting that instrumentation right requires understanding a few things about how Supabase and Sentry fit together.

Supabase's built-in observability and its limits

Supabase has solid built-in observability. The Query Performance panel in the dashboard shows which queries run most often and which consume the most time. That's where you start when performance is the problem. The Advisors surface security issues like missing RLS policies and rank them by severity. The Index Advisor flags missing indexes before they become production incidents.

The Logs section gives you structured logs from every Supabase subsystem: edge functions, the Postgres REST API (PostgREST), the connection pooler, storage, and cron jobs. You can query them with SQL directly in the dashboard.

That's genuinely useful. But it's bounded by what Supabase can see, which is everything that happens inside Supabase. It can't tell you that a slow Postgres query was triggered by a specific user action in your Next.js frontend, or that an edge function timeout caused a cascade of errors in your API layer. For that, you need distributed tracing across the full stack.

Connecting Supabase logs to Sentry

The fastest way to get Supabase data into Sentry is the log drain. In the Supabase dashboard, under Logs > Drain, you add a destination and paste your Sentry data source name (DSN). All logs from that Supabase project start flowing into a corresponding Sentry project.

A few things worth knowing about this:

It's currently all-or-nothing. You can't filter by log level on the Supabase side before the drain
Once logs are in Sentry, you can filter by severity (severity:warn, severity:error) in the Log Explorer
Keep the log drain in its own Sentry project, separate from your Next.js app and your edge functions. This keeps the signal clean and makes it easier to set project-specific alerts

The reason to bother with this, beyond convenience, is that Sentry can correlate these infrastructure logs with traces from your application layer. When an edge function throws an error, you can see the full request path: Next.js page load → API route → edge function → Postgres query, with timing for each span.

For a step-by-step walkthrough of this setup, see the Supabase log drain monitoring recipe.

Instrumenting Next.js and Supabase Edge Functions

This is where most agent-generated setups go wrong. Next.js is a full-stack framework that runs in multiple runtimes: Node.js on the server, V8 in the browser, and potentially edge runtimes. Supabase Edge Functions run in Deno. These are not the same environment, and they need separate Sentry projects and separate SDK configurations.

The Sentry CLI handles this detection automatically:

npx sentry@latest init

For the Next.js app, your sentry.server.config.ts should include the Supabase integration to get automatic instrumentation of database queries:




const supabaseClient = createClient(
  process.env.NEXT_PUBLIC_SUPABASE_URL!,
  process.env.SUPABASE_SERVICE_ROLE_KEY!
);

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  tracesSampleRate: 0.1,
  integrations: [
    // Instruments Supabase queries as spans in your traces
    // so you can see exactly which DB calls are slow
    Sentry.supabaseIntegration(supabaseClient, Sentry, {
      tracing: true,
      breadcrumbs: true,
    }),
  ],
});

Without the Supabase integration, your traces will show that an API route was slow, but not which query caused it. With it, every Supabase SDK call becomes a named span with timing data. See the Next.js integrations docs for the full list of what's available.

For edge functions running in Deno, initialize Sentry at the top of each function before any other imports:



Sentry.init({
  dsn: Deno.env.get("SENTRY_DSN"),
  tracesSampleRate: 1.0, // sample everything in edge functions; volume is usually low
});

Deno.serve(async (req) => {
  return await Sentry.withIsolationScope(async () => {
    // your handler code
  });
});

The reason for separate projects: when Sentry's AI features (more on this below) analyze an issue, they work within a project's context. Mixing Next.js errors with Deno errors and Postgres logs in a single project makes that analysis noisier and less useful.

Automatic detection: N+1 queries, slow spans, and Web Vitals

Once instrumented, Sentry starts surfacing issues you didn't know to look for.

N+1 queries get detected automatically. If your code fetches a list of posts and then queries the database once per post to get comments, Sentry identifies the pattern and creates a performance issue. This is the kind of "logic" agents like to write constantly. It's the natural way to express the functionality, and it's invisible until you have real traffic.
Slow spans appear in the Trace Explorer. You can see exactly which database query, API call, or server-side render is consuming time, with the full request context attached.
Core Web Vitals for the frontend (LCP, INP, CLS) show up in the Next.js performance dashboard alongside your API latency and server transaction data. Having frontend and backend performance in one place makes it easier to figure out whether a slow page is a rendering problem or a slow API response.

The prebuilt Next.js dashboard in Sentry covers most of what you need out of the box and doesn't count against your dashboard quota.

Setting up agents to instrument correctly

Two things make the difference between an agent that instruments your app correctly and one that produces outdated, incomplete configuration.

MCPs over training data

Both Sentry and Supabase have Model Context Protocol (MCP) servers. When your coding agent has access to the Sentry MCP, it can query your actual issues, traces, and project configuration in real time instead of guessing based on training data that might be two years old. Sentry's SDK has changed significantly, and agents without current context will often configure it as if it's only for error monitoring, missing performance tracing entirely.

Skills files

For Claude Code, this is .claude/. For Cursor and others, .agents/. These files give your agent project-specific context that persists across sessions. Take a look at our Agent Skills documentation for a detailed breakdown of all the skills Sentry offers.

A practical workflow: when you need to add Sentry to a project, go to the Sentry docs, find the SDK for your framework, copy the setup prompt they provide, and give that to your agent. The docs include current best practices and the right SDK version. Don't just tell the agent to "add Sentry." It will find a way to do it, and the result will probably work, but it won't be right.

Monitoring beyond errors

Errors are the obvious case. But some of the most useful monitoring is for things that aren't errors.

Log-based monitors let you alert on patterns in your log stream. If you're draining Supabase logs into Sentry, you can create a monitor that fires when the count of connection received logs drops below a threshold in a given hour. Not an error, just a signal that something might be wrong with your database connectivity. In the Sentry UI: Alerts > Create Alert > Logs, filter by message content, set a count threshold, and assign it to yourself or a team.
Dynamic alerting is useful when you don't know your normal thresholds yet. Set an alert to use anomaly detection instead of a fixed value. Sentry's ML figures out what "normal" looks like for your transaction response times and fires when something falls outside that pattern. Start with dynamic, tune to specific values once you understand your baseline.
Sentry CLI for dashboards: The new Sentry CLI has a dashboards command that an agent can use to build a custom dashboard from your actual trace data. Point it at your project, ask it to build a performance dashboard for your application, and it will inspect your active transactions and spans to figure out what's worth visualizing. The output isn't perfect (you'll want to review widget configurations), but it's a reasonable starting point that takes about thirty seconds instead of thirty minutes.

Seer: from alert to fix

Seer is Sentry's AI debugger. It has access to your full issue history, traces, logs, and session replays. You can ask it plain questions: "which of my open issues are getting worse?" or "what are my slowest database queries?" and it will pull from your actual data to answer.

The more interesting capability is Autofix. Configure it in your Sentry project settings by connecting your repository. When a new issue comes in, Seer automatically suggests a likely root cause and, if you want, generates a draft PR with a suggested fix. You can configure how far it goes: root cause only, or full fix with updated tests.

For the Supabase security advisory workflow: the Supabase MCP exposes RLS policy issues and other advisories. An agent with both the Supabase MCP and the Sentry MCP can fetch those advisories and create Sentry issues from them, putting security problems into the same workflow as application errors. From there, Seer can pick them up and attempt fixes automatically.

This is what "self-healing software" actually looks like in practice: not magic, but a pipeline where new issues get triaged, analyzed, and handed to a coding agent without you having to be the one who notices them first.

Where to start

The fastest path is three steps: run npx sentry@latest init to instrument your Next.js app, add the Supabase integration to your server config for query-level spans. Then set up a log drain from Supabase into its own Sentry project. That gets you unified tracing across the full stack. From there, connect your repo to Seer and let it start suggesting fixes for new issues as they come in.

The Sentry Supabase integration docs cover setup end to end. Supabase has their own Sentry monitoring guide and a separate guide for edge function monitoring.

Monitor Unreal Engine Game Performance with Application Metrics

Fri, 08 May 2026 00:00:00 GMT

Your Unreal game can ship with zero errors and still not feel great. Stutters during combat, a frame-rate cliff on the big boss, rubber-banding in multiplayer, none of it shows up as a crash and none of it shows up in Sentry, leaving you without any visibility into what your players are actually experiencing in the wild. Well, until now.

Unreal Engine already gives you plenty of tools to measure game performance and collect runtime stats, but all that data stays on the dev's machine.

The Unreal SDK's new automatic performance metrics feature closes this gap by piping FPS, frame time, network health, and other common game telemetry straight to Sentry, so your team gets actionable insight into where performance breaks down, on which hardware, for which players. Pair it with Release & Health and you can watch the performance impact of each release land over time.

A quick note before we dig in: every gamedev has used a profiler at some point. Automatic performance metrics are a different-but-related tool, both go after the same problem at different layers: metrics find where the game is slowing down, profiling explains why.

What Sentry now tracks

Currently, Unreal SDK auto-instruments metrics for several key areas that impact overall performance including frame time, network and game-specific stats.

Frame time

The most direct read on whether your game feels responsive. Frame times tell you "how long the engine spent on each frame"; breaking it down by thread tells you which subsystem is the bottleneck.

Average FPS
Total frame time
Game thread work time
Render thread work time
GPU frame time

Comparing game thread vs render thread vs GPU time is the classic way to tell whether you're CPU-bound or GPU-bound and which team (gameplay, rendering, content) owns the fix.

FPS metric example (grouped by GPU)

Network insights

Multiplayer performance lives or dies by connection quality, and crash reporting can't see any of it. These metrics tell you whether packet loss, latency or bandwidth starvation is quietly degrading the experience.

Incoming/outgoing bandwidth
Packet throughput and loss
Client ping and jitter
Active connection count

Server builds additionally get per-client ping averages, per-client bandwidth and saturated-connection counts for load-shedding analysis (see the full list of network metrics).

These metrics only exist during active multiplayer sessions. Singleplayer games without networking emit nothing here and some values are client-only (ping, jitter) or server-only (active clients, saturation).

Ping metric example

Game stats

A small grab-bag of engine-level signals that often explain hitches the frame-time breakdown alone can't.

Number of active UObjects
Physical memory used by the process
Duration of the blocking GC pause

A UObject count that climbs steadily between GCs is a classic leak signature and correlating it with GC pause duration often reveals exactly when a leak starts hurting player experience.

Unlike frame time, these are sampled on a slower cadence: memory and object count every 60 seconds, GC pause emitted after each collection cycle. Values change slowly enough that per-frame resolution would be wasted throughput.

Used Memory metric example (grouped by platform, console-only)

Sampling performance metrics

Emitting a metric every frame would be an overhead on its own. To avoid that, the SDK samples at a fixed interval, emitting one data point every N frames for per-frame metrics like frame time and FPS, and every N seconds for slower-changing ones like memory use or network health. The defaults are conservative and tunable per project:

~2 samples per second for frame time at 60 FPS
Every 10 seconds for network
Every 60 seconds for game stats

On any single client this is sparse, a hitch on a non-sampled frame won't be captured. But across many players the aggregate distribution converges on the real picture. You want to know "what's the p95 frame time on RTX 3050 hardware?", not "what did frame #47312 look like on dev's laptop." If you need tighter resolution simply dial the interval down.

Metrics attributes

An aggregate FPS number on its own doesn't tell you much. What makes it useful is breaking it down: per GPU, per platform, per level. Every automatic metric is tagged with context attributes so you can do exactly that:

GPU model name
Number of CPU cores
Total physical RAM
Screen resolution
Current game map/level name

Metrics also carry the release version, operating system, and crucially the trace ID of whatever was happening when they were emitted. That last one is what separates metrics-in-Sentry from a standalone monitoring tool: spot a frame-time spike in the dashboard, click into the sample and you land in the full trace for that moment alongside any errors and spans captured with it.

For example, group FPS (game.perf.fps) by GPU (gpu.name) and the answer to "what FPS do RTX 3080 players actually see versus RTX 3050?" is one query away. Swap the grouping to OS (os.name) and you can compare memory footprint across Xbox, PlayStation and Switch.

Try it out and tell us what's next

Automatic performance metrics are enabled by default in Unreal SDK 1.11.0. See the Unreal SDK metrics docs for more on engine-version requirements and advanced configuration. Automatic metrics work on desktop, consoles and Android (with iOS support coming soon).

Ship a build with automatic performance metrics enabled and let it run for a few sessions, that's often enough to see whether hardware segmentation, frame-time percentiles or network health are already surfacing something worth fixing.

And since the feature is still experimental, what gets measured next is up for grabs. If there's a signal you wish we were capturing, open an issue on the Unreal SDK repo, as that's the best way to shape where this goes.

Have questions or feedback?

Join the conversation in our Discord
Email us at gaming-updates@sentry.io

New to Sentry?

Try Sentry for free

Fixing JavaScript observability, one library at a time

Thu, 07 May 2026 00:00:00 GMT

Over the past few weeks, we have been driving a cross-ecosystem effort to replace the "monkey-patching" that powers all JavaScript APM tools today with something built into the runtime. Here is why, how, and where it stands.

This applies to server-side JavaScript only (Node.js, Bun, Deno, Cloudflare Workers). Browsers do not have diagnostics_channel and lack the async context propagation primitives needed to polyfill it.

Monkey-patching does not scale

My teammate Sigrid wrote a detailed breakdown of why monkey-patching is failing and how TracingChannel solves it.

The short version: every JavaScript APM tool, including Sentry's, instruments libraries by intercepting require() and import calls at runtime using import-in-the-middle (IITM) and require-in-the-middle (RITM). This breaks with ECMAScript Modules (ESM), does not work in non-Node runtimes, conflicts with bundlers, and couples us to internal implementation details we do not control. The SDK also must load before the library it instruments, or instrumentation silently does nothing.

This is not a Sentry-specific problem. Every APM vendor maintaining JavaScript instrumentation deals with the same fragility. The ecosystem is stuck.

Most library maintainers do not think about observability. They do not know what they would need to expose, and adopting something like OpenTelemetry means taking on an implementation burden, not just adding a standard. APMs managed to patch their way around this for years, so nobody on the library side ever had to figure it out.

But there's a better way.

TracingChannels - observability without patching

In late 2025, we were working with Pooya Parsa (creator of Nitro, h3, and the unjs ecosystem) on the best way to build a Sentry SDK for the Nitro framework. During that conversation, my teammate Sigrid suggested we look into TracingChannel, a built-in API from Node's diagnostics_channel module. Sigrid's blog post covers that API in depth, but the core idea is simple: if a library publishes structured events on a TracingChannel, any APM tool can subscribe to those events without patching anything. The library just says "a query started" and "a query ended," and whoever is listening can create spans from that.

// Library side (e.g. inside mysql2)


const queryChannel = tracingChannel('mysql2:query');

queryChannel.tracePromise(async () => {
  return await connection.query(sql);
}, { query: sql, serverAddress: host, serverPort: port });

The cost of this added code is minimal, so this is an easy sell for library maintainers. From APM's side, we just need to subscribe to that tracing channel and we get the events. No IITM, no RITM, no loader hooks, no initialization ordering. Zero overhead when nobody is listening. Works across Node, Bun, and Deno. Bundler safe. The API has been available since Node 18, and dc-polyfill covers runtimes that lack it, which already matches our support range.

Everyone agrees, nobody is pushing

After getting enough learnings about the tracing channel API and how to make it work with OpenTelemetry, I opened an issue on Otel JS in November 2025 to discuss TracingChannel support.

The response was positive. A while after, someone from the OTel team even created a draft API approach for integrating TracingChannel into the OTel SDK.

But there is no significant push to drive ecosystem adoption. The draft exists; the ecosystem work does not.

Everyone agrees that TracingChannel is the future of JavaScript observability, but nobody is doing the work of getting libraries to adopt it. We have many instrumentations across databases, web frameworks, message queues, and AI providers that need TracingChannel support. That is a mountain of upstream PRs, each requiring understanding the library's internals, writing a proposal that maintainers will accept, implementing the changes, and iterating on review feedback.

So I thought "fine, why not just get the ball rolling?"

The first step was proving the pattern works. I had already built TracingChannel support by hand in h3, srvx, unstorage, db0, and Nitro as part of the earlier SDK work. The unjs ecosystem was receptive and moved fast, which gave us shipped examples to point to and an end-to-end mental model: how events should be shaped, how context propagation flows, how to make it work with OTel, and what semantic conventions to follow.

We also learned early that you can't just say "hey you should use TracingChannel," which is just begging to be shelved to collect dust. Instead, like we did with Nitro, we say "Hey, we will do it for you and help you own it." Accepting code into a repository adds a burden of maintenance, so we offer to help own it and make it part of the library.

With that in mind, I reached out to pg, mysql2, and redis to gauge their interest, offering to fully own this 'til it ships and provide support even after. These are the top database driver libraries in the ecosystem, accounting for over 60 million downloads per week combined. If we can get TracingChannel in them, we can get other libraries. All three said yes and were open to receiving a PR.

I also reached out to Stephen Belanger, the creator of the diagnostics_channel API in Node.js core. He is now helping push this forward, providing feedback on proposals and acting as the voice of authority which is sometimes needed to convince maintainers.

So one by one, we're making this happen across the ecosystem.

For context on how this fits into the bigger picture: My team is working on making our SDK runtime-agnostic, we are working multiple paths in parallel, most of which have an immediate effect. The TracingChannel initiative work is the long-term play. We cannot expect users to upgrade to new library versions overnight, and we probably won't convince everyone to implement them at the same time so the migration will be gradual.

Scaling it with AI

Here is the practical reality: Being one person trying to add TracingChannel support to 44 libraries is just not going to happen. I do not know the internals of any of them. I have never looked at the Redis protocol implementation or mysql2's query pipeline before this project.

So I built a feedback loop using Claude Code that handles the per-library heavy lifting via SKILLS:

Research and Propose. Given a library name, Claude researches its async model, existing OTel instrumentation, maintenance status, and internal architecture, then drafts a proposal following all the patterns we have established. I review and adjust before it goes anywhere.
Implement. Given an approved proposal, Claude produces a working implementation with tests, handling tracePromise/traceCallback selection, hasSubscribers guards, Node 18 compatibility, and integration tests against real services via Docker.
Capture Review Feedback. When a PR gets reviewed upstream, Claude triages every comment, assesses validity, suggests responses, and flags patterns that should inform future proposals. I decide what to act on and handle all communication with maintainers myself.
Update the Tracker. Claude fetches the latest status of every upstream PR and keeps the migration tracker current.

Each cycle feeds the next one. Learnings from one library's review process improve the next library's proposal. The knowledge compounds and is dumped into a LEARNING.md file to guide future work.

To clarify the human/AI split: Claude handles research, boilerplate implementation, and pattern application. I handle architecture decisions, insertion point identification, all maintainer communication, and final review of every line before it ships. Critically, every commit is co-authored and AI involvement is made transparent. Library maintainers interact with a human, not with an AI. I kept certain parts human-led because that shows respect to the maintainer's work, which is critical to convincing them to adopt code into their library.

This approach turned what would be a multi-year solo effort into a production line where I can keep dishing out proposals every day, start implementations in parallel, learn from them all and integrate the learnings into pending and future work.

10 merged, 34 to go

We are tracking many instrumentations across four categories. Here is where things stand:

Category	Total	Merged	PR Open	In Discussion	Not Started
OTel-provided	24	4	2	6	12
Sentry-built	10	0	0	1	9
Other ecosystem	8	5	2	1	0
Logging	2	1	0	0	1
Total	44	10	4	8	22

Notable wins:

mysql2 - Merged. One of the most popular database drivers in the npm ecosystem.
node-redis and ioredis - Both merged. The two dominant Redis clients now ship TracingChannel support.
h3, srvx, unstorage - All merged. The unjs ecosystem was early and enthusiastic. This touches Nitro, which in turn touches Nuxt and other downstream frameworks.

We also helped establish ecosystem coordination through an e18e umbrella issue and the untracing spec that standardizes TracingChannel usage for library authors.

What this means for Sentry

This flips the instrumentation model. Libraries own the contract, and we subscribe to it. Every problem described above (ESM breakage, init ordering, runtime lock-in, bundler conflicts) goes away. Our instrumentation code gets simpler, and we stop maintaining runtime-specific hacks.

This also benefits every APM tool, not just Sentry. Driving it builds trust with library maintainers and the broader community, sure, but several maintainers have specifically called out that they appreciate the approach because it helps everyone and is not biased towards any one APM provider.

The flywheel is starting

Take node-redis as a case study. During our collaboration with the Redis team, they were already working on their own first-party OpenTelemetry instrumentation. They wanted our TracingChannel proposal to align with and power that instrumentation. We re-implemented their already shipped metrics plugin using tracing channels and it worked without changing a single test. Now, we are helping them with traces.

Shortly after mysql2 shipped TracingChannel support, someone independently built mysql2-otel-instrumentation, a pure diagnostics_channel subscriber that replaces OTel's monkey-patched @opentelemetry/instrumentation-mysql2. The motivation was exactly the problem we are solving: RITM was not working. A library adds TracingChannel support, and the subscribers manifest on their own.

What's next

We have open PRs against Express, PostgreSQL (pg), Knex, and GraphQL, the kind of libraries where TracingChannel support means millions of applications get better observability without changing a line of their own code. MongoDB, Mongoose, Prisma, and Hono are in active discussion, and we have drafted proposals for Koa and Consola. There are still 20+ libraries on the list we have not reached out to yet, including Node's built-in HTTP module, Kafka clients, and AI provider SDKs.

Beyond individual library adoption, the next layer is reducing duplication on the consumer side. Right now, every APM tool that subscribes to a TracingChannel has to independently map library payloads to OpenTelemetry semantic conventions. We are designing a shared mapper registry, a set of co-maintained modules that translate TracingChannel events into standardized spans and attributes. The goal is to build and prove this internally at Sentry first, then open-source it so any APM vendor can plug in. If a library ships TracingChannel support and a mapper exists, instrumentation becomes automatic.

The long-term picture is an ecosystem where libraries emit events as a first-class concern, mappers are community-maintained, and APM tools compete on what they do with the data rather than on how creatively they can patch your dependencies. We are not there yet, but the flywheel is turning.

You can help by talking about tracing channels and advocating for their adoption in the libraries you use. If you maintain a library and want to add TracingChannel support, the untracing conventions and our published proposals are a good starting point.

Improved debugging for Expo apps with the React Native SDK

Wed, 06 May 2026 09:00:00 GMT

Events from Expo apps account for about 75% of the total event volume we receive from React Native apps. That number made it an easy decision to invest in updates to the Sentry React Native SDK to improve the debugging and performance workflow for your Expo apps.

With these updates, you can now:

Filter issues by OTA update channel or version to instantly narrow down whether a problem is tied to a specific update
Get alerted on emergency launches so you know when your OTA pipeline is failing before users report it
Track EAS Build health in Sentry so you don't have to dig through build logs to find out what broke
See the full picture of navigation performance including prefetch timing and asset loading

Automatic OTA update context on every event

When you ship over-the-air updates with Expo Updates, things can go wrong in ways that are invisible without the right context. Which update channel was the user on? Which runtime version? Was this the embedded bundle or a downloaded update?

Now, every Sentry event is automatically enriched with an ota_updates context, with no other setup required. You get the update ID, channel, runtime version, launch duration, and whether the app is using embedded assets. All of this is captured out of the box in Expo projects.

We also set searchable tags (expo.updates.channel, expo.updates.runtime_version, expo.updates.update_id) on every event, so you can filter your issue stream down to a specific channel or update with a single search query.

Emergency launch detection

Expo Updates performs an emergency launch when it fails to load the latest OTA update and falls back to the embedded bundle. When this happens, your users are silently running an older version of your app, and you might not even know.

The SDK now detects emergency launches at startup and automatically sends a warning-level event to Sentry with the reason. You can set up an alert on the expo.updates.emergency_launch tag and know immediately when your update pipeline is broken in production.

EAS build hooks: Track build failures in Sentry

Build failures in EAS Build happen on remote infrastructure, outside your local environment and outside your app. Until now, debugging them meant digging through EAS build logs manually.

With the new EAS Build Hooks, you can send build lifecycle events directly to Sentry. Add three script entries to your package.json (or just one if you prefer the combined on-complete hook) and every failed build will send an EASBuildError event with the build platform, profile, build ID, git commit hash, and CI status.

You can also capture successful builds to give you a complete picture of your build pipeline health right inside Sentry. All events are tagged with eas.* tags for easy filtering and alerting.

Setup is minimal: point the hook scripts at the ones the SDK provides, set your DSN as an EAS secret, and you're done. Check out the EAS Build Hooks documentation for setup instructions.

Performance spans for Expo Router prefetching

Expo Router v5 introduced router.prefetch() to preload routes before the user navigates to them. It's a great tool for perceived performance, but until now, prefetch timing was invisible in your traces.

Wrapping your router with Sentry.wrapExpoRouter(useRouter()) now creates a navigation.prefetch span for each prefetch call. You can see exactly how long route preloading takes alongside your other navigation spans, and identify routes where prefetching is slow or unnecessary.

Expo constants and environment context

Every event from an Expo app is automatically enriched with an expo_constants context containing metadata about the execution environment: where the app is running (Expo Go, standalone, bare), the app name and version from app.json, Expo SDK version, EAS project ID, and debug mode status.

Combined with the OTA updates context, this gives you a complete picture of the environment for every event without writing a single line of configuration code.

Image and asset loading instrumentation

Image and asset loading is one of the biggest contributors to how fast your app feels. We've added automatic performance spans for two of the most common Expo packages:

expo-image: Wrap Image with Sentry.wrapExpoImage(Image) once at startup, and every Image.prefetch() and Image.loadAsync() call gets a performance span.
expo-asset: Wrap Asset with Sentry.wrapExpoAsset(Asset) for spans on Asset.loadAsync().

Both wrappers are safe to call multiple times, create spans only when a trace is active (zero overhead otherwise), and don't require expo-image or expo-asset to be installed. They're peer dependencies.

Getting started

All of the OTA update and constants context is enabled by default. No configuration, no extra dependencies. For build hooks and performance instrumentation, setup is a few lines of code. Make sure you're on version 8.10 to get the latest improvements and fixes.

Expo also allows you to pull in issue details and replays from Sentry for errors occurring in your EAS deployments.

Don't have a Sentry account yet? Sign up for free, the developer plan includes everything you need to instrument an Expo app end to end. Have feedback on these integrations or ideas for what should come next? Open an issue on getsentry/sentry-react-native or drop into our Discord.

Introducing Application Metrics: Track the signal, see the spike, jump to the trace

Tue, 05 May 2026 00:00:00 GMT

A few weeks ago we had a bug with Session Replay. Replays were failing in some browsers once more than 1,000 video segments loaded. We had no idea how often it happened or who was hitting it, and because the failure didn't always produce an error, we had no way to find affected users to reproduce it.

Before, we could've answered this with spans or logs, but it's clunky — spans are often sampled, so you can miss outliers; logs are less structured and tend to change over time. Both are better suited for investigation. Metrics are ideal for tracking known behaviors over time. So we set up a metric in the Sentry SDK with a user and provider attribute, filtered for sessions over 1,000 segments, and had a repro case in minutes.

That's the job Application Metrics is for: track the signals you care about, and attach the context you might need later. When something breaks, the data is already there waiting.

Full events, not pre-aggregated counters

Metrics tools designed for tracking infrastructure telemetry tend to aggregate, stripping out information like user, IP address, and region. They're just a counter.

Sentry's Application Metrics stores full events, including high-cardinality fields like user. So you're able to ask not just "was the checkout experience slow in my application?", but "was the checkout experience slow for users on the east coast?", or "was a specific user's scheduled job causing a queue backlog?"

Same SDK, one line of code

If you're on a recent Sentry SDK, metrics are already enabled. No new dependencies or sidecar — just one more line.

There are three types you'll reach for most:

Counter — increment a number each time something happens. Think payment.declined, search.zero_results, or email.failed. Good for tracking rates and totals you want to alert on.
Distribution — record a value each time something happens, then ask questions about the spread. How long did that job take? How many items were in the queue? Use this when the average isn't the whole story.
Gauge — track a current value over time. queue.depth, cache.size, active.connections. The number you'd want on a dashboard.

You can attach attributes to all three. That's where Application Metrics differs from many infrastructure monitoring tools, which pre-aggregate and strip context. When you attach user.id, region, or projectId, the event is stored with that context intact — so when a distribution spikes, you're not just looking at a number, you're looking at a number tied to a specific user, in a specific region, on a specific project.

Click a spike, see the trace

By storing full metrics events — including the trace ID — metrics become part of a broader trace-connected debugging workflow.

When a metric reaches an unexpected threshold (a background job backing up with unsent emails; a UI component taking painfully long to load) you can jump from that metric to traces, logs, and errors, and get a full picture of what actually went wrong around the time your pager went off:

Is a 429 error happening in a loop at the same time that a distribution measuring React component load times spikes?
Is an upstream email service running slow at the same time that a gauge measuring queue depth increases?

How we actually used this to find a Session Replay bug

To investigate the Session Replay problem, we began by adding a distribution that tracked the number of video segments loaded. We included the high-cardinality projectId attribute.

Here's the code we added to start tracking video segments in replays:

const replayId = replay?.getReplay().id;
const projectId = replay?.getReplay().project_id;

const onLoadAllEvents = useEffectEvent(() => {
  const attributes = {
    projectId: String(projectId),
    replayId,
  };

  Sentry.metrics.distribution('replay.eventCount', events?.length ?? 0, {
    attributes,
  });

  Sentry.metrics.distribution('replay.videoEventCount', videoEvents?.length ?? 0, {
    attributes,
  });
});

See getsentry/sentry#114001.

We attached replayId and projectId as attributes on the scope so we could isolate high event counts to specific projects and replays. Given that we were having trouble reproducing the problem, this would help us catch the issue red-handed, tracing it back to a specific organization.

With that in place, we quickly learned two things:

The issue was rare — just 7 occurrences in the past week.
We had the exact users affected.

From there, we could trace those sessions, reproduce the issue, and fix it.

Because each metric event carries a trace ID, we could go further. We added targeted logs to see exactly what the user was doing when >1,000 frames loaded — were they scrubbing the video, loading many videos in succession, etc. Next time we saw a replay.videoEventCount over 1,000, we jumped to the connected trace, saw the log lines, and had the context to fix the bug.

Metrics vs. everything else

Metrics aren't a replacement for errors, traces, or logs. They fill a specific gap: tracking interesting, well-understood events in your application with high fidelity.

Not every event needs to be a metric. Logs are great during investigation. But when you find a signal you care about long-term — something that tracks application health — turn it into a metric.

Good candidates: business KPIs tied to code execution (payment.declined, search.zero_results), application health indicators (job.retried, email.failed), resource utilization (queue.depth, cache.hit_rate), and success/failure rates you want to alert on.

Not the right fit: infrastructure metrics like CPU and memory (use your infra tool), forensic debugging (use Sentry Logs), or request-level performance and connectivity (use Sentry Tracing).

Start with the metric your team checks first

Every Sentry plan comes with 5GB of Application Metrics. If you're on a recent SDK version, you already have access.

Pick the one signal your team reaches for first when something goes wrong. Maybe it's checkout.failed, maybe it's queue.depth, maybe it's deployment.duration. Instrument it, attach the attributes you'd want to filter on — user, project, region, whatever matters for that metric — and set an alert threshold.

When it fires, click through to the trace, find the context around the spike, and fix it.

Start a free Application Metrics trial in Explore > Metrics, or check out the Application Metrics docs →.

Two commands to Sentry: now on Stripe Projects

Wed, 29 Apr 2026 07:00:00 GMT

Two commands. That's how little it takes to go from nothing to a fully configured Sentry project with error monitoring, performance tracing, and session replay:

stripe projects init my-app
stripe projects add sentry/project

No signup form. No email verification dance. No dashboard tab-switching to copy-paste a DSN into your .env. Your account is created, your project is provisioned, and five environment variables land in your working directory, ready for your SDK to pick up.

And if you're using a coding agent? It does the same thing, except you didn't type the commands. You just said "add error monitoring."

What this actually is

Sentry is now a provider in Stripe Projects. Stripe Projects is a CLI workflow that lets developers (and their AI agents) discover, provision, and manage infrastructure services directly from the terminal. Think of it as a package manager, but for the services your app depends on at runtime.

Here's the full catalog:

$ stripe projects catalog sentry

SERVICES
    project   ● Free tier
    seer      ● Paid

PLANS
    developer ● Free
    team      ● $29/month
    business  ● $89/month

Two deployable services (a Sentry project and Seer AI), three plan tiers. All manageable from the CLI. Billing goes through your existing Stripe payment method, with no separate Sentry billing setup.

The "just tell your agent" part

When you run stripe projects init, it scaffolds agent skill files into your project:

.agents/skills/stripe-projects-cli/SKILL.md
.claude/skills/stripe-projects-cli/SKILL.md
.cursor/rules/stripe-projects-cli.md

These teach Claude Code, Cursor, or any coding agent how to use the Stripe Projects CLI. The agent reads the skill, discovers available services via stripe projects catalog sentry --json, and provisions what you need.

A real interaction looks like this:

You: "Add error monitoring to this project"

Agent: [runs stripe projects catalog sentry --json]
Agent: [runs stripe projects add sentry/project --no-interactive --accept-tos]
Agent: "Done. Sentry is provisioned. Your DSN and auth token are in .env.
        I can integrate the Sentry SDK into your app next."

The agent doesn't need special Sentry knowledge. It just needs the Stripe Projects CLI and the skill file that init already created. Provisioning becomes a step it handles between writing your code and running your tests.

Once the account is provisioned, you can ask the agent to instrument your app with sentry init. Since the auth token and DSN are already in the environment, the Sentry CLI knows exactly which project to target, with no configuration prompts, no guesswork.

Upgrades, downgrades, and the billing dance

Plans are first-class resources:

stripe projects add sentry/team                          # start on Team ($29/mo)
stripe projects upgrade sentry-plan sentry/business      # upgrade to Business
stripe projects downgrade sentry-plan sentry/team        # change your mind

All non-interactive, all scriptable. Billing happens through Stripe's Shared Payment Token, so your existing Stripe payment method pays for Sentry with zero billing configuration on the Sentry side.

You can also add Seer (our AI debugging assistant) as a separate service:

stripe projects add sentry/seer      # $40/active contributor/month
stripe projects remove sentry-seer   # if you change your mind

The magic login

This one's my favorite. When you need your Sentry dashboard:

stripe projects open sentry

This mints a single-use magic login URL. Click it (or let the CLI open it), and you're logged into your Sentry dashboard. You skip the password prompt, the single sign-on (SSO) redirect, and the "which account was this again?" moment. Straight to your issues page.

It's the kind of feature that sounds trivial but has a surprisingly dense security model once you start thinking about two-factor authentication (2FA) users, expired passwords, and SSO bypass prevention.

Multi-team collaboration

Here's where it gets interesting. Stripe's protocol distinguishes between the account owner (the Stripe account's email) and the actor (the person running the CLI command). We use this to build a proper collaboration model:

First team member runs stripe projects add sentry/project → creates the Sentry org
Second team member runs the same command → joins the same Sentry org
Everyone shares one org, one billing setup, one set of projects

We tie the Sentry organization to the Stripe organization, so everyone on the same Stripe account ends up in the same Sentry org. No per-developer silos, no "who created this and why can't I see it" conversations.

Credential rotation

stripe projects rotate sentry-project

New DSN, new auth token, old ones revoked. The fresh credentials land in your .env automatically. The dashboard stays closed.

How to try it

Install the Stripe CLI and the Projects plugin:
```
stripe plugin install projects
```

Initialize and add Sentry:

stripe projects init my-app
stripe projects add sentry/project

That's it. Your SENTRY_DSN and SENTRY_AUTH_TOKEN are in .env, ready for any Sentry SDK to pick up.

For the full lifecycle (catalog browsing, plan management, Seer, deep links, credential rotation), check the Stripe Projects documentation.

If you're building with AI coding agents and want error monitoring that provisions itself, give it a try. And if your agent breaks something in the process, well, you'll have Sentry to tell you about it.

Sentry's integration with Perforce is now generally available

Wed, 29 Apr 2026 00:00:00 GMT

Perforce meets Sentry

If you work in game development, VFX, or any industry dealing with large binary assets, chances are your codebase lives in Perforce P4. It's the version control system behind some of the biggest games and creative projects in the world — and until now, it's been one of the last major SCMs without first-class Sentry support.

Today, we're changing that. The Sentry + Perforce P4 integration is now generally available for all Sentry organizations.

What you get

The integration connects your P4 server directly to Sentry, unlocking the same source-code-aware debugging workflows that Git-based teams have relied on for years:

Stack trace linking — Click from an error's stack trace directly to the corresponding file in your Perforce P4 depot or P4 Code Review (formerly Helix Swarm) instance.
Commit tracking — Associate Perforce P4 changelists with Sentry releases so you always know exactly what code shipped.
Suspect commits — Sentry automatically identifies which changelists likely introduced an error, cutting your triage time.
Suggested assignees — Get assignment recommendations based on changelist authorship — the person who last touched the code gets surfaced first.
P4 Code Review (formerly Swarm) linking — If your team uses the P4 Code Review (formerly Helix Swarm) application for code reviews and browser-based depot browsing, Sentry links directly to your P4 Code Review instance. Stack trace links open the exact file in P4 Code Review's web UI, so reviewers and investigators can jump from an error straight into the code without needing a local workspace.

On-demand source context

The most requested capability during our beta: show me the code. Previously, showing the source code for native crashes required users to upload source maps to Sentry. Without source maps, showing the stacktraces was possible, but they didn't have source context.

With on-demand SCM source context, Sentry fetches source code directly from your Perforce P4 depot and displays it inline in the stack trace — even when your crash dumps or error reports don't include embedded source. Expand any in-app frame and Sentry pulls the relevant lines on the fly, with the error line highlighted.

This is especially valuable for native game development workflows where minidumps and crash reports rarely carry source context. Instead of switching to your IDE or running p4 print manually, the code is right there in the issue.

How it works

Setup takes just a few minutes:

Connect your server — Go to Settings > Integrations > Perforce and enter your credentials.
Configure code mappings — Map your Sentry projects to Perforce P4 depots and set up path translations.
Enable source context (optional) — Turn on SCM source context in your project's General Settings to get inline code in stack traces.

Sentry communicates with your Perforce P4 server using the P4Python library, executing lightweight read-only commands (p4 depots, p4 changes, p4 print). Each organization maintains isolated credentials, and we support both password-based auth and pre-generated P4 tickets for LDAP environments.

How to get started

During beta, we worked closely with multiple game studios to battle-test the integration against real-world Perforce P4 deployments. We resolved concurrency challenges around P4 trust and ticket file isolation, ensuring connections stay clean and independent — whether you have one project or hundreds hitting the same or multiple servers.

The Perforce integration is available now for all Sentry organizations.

Read the Docs

Have questions or feedback?

Join the conversation in our Discord
Email us at gaming-updates@sentry.io

New to Sentry?

Try Sentry for free