Operations | Monitoring | ITSM | DevOps | Cloud

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

When you ship a Next.js app, the React and TypeScript you write aren’t what your users actually download. Next.js compiles, minifies, splits, and shuffles your code into chunks in ways that are great for performance and terrible for debugging. This post shows you how that pipeline works, how source maps and debug IDs connect it all back to your original code, and how to wire things up so Sentry shows you real file names and line numbers instead of an unreadable stack trace.

AI-driven caching strategies and instrumentation

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

Sentry acquires XcodeBuildMCP

Today we're announcing that Sentry has acquired XcodeBuildMCP, an open source MCP server that gives AI agents the ability to build, test, and debug native iOS and macOS apps. XcodeBuildMCP has become a go-to tool for agentic Apple-platform development, with more than 4,000 GitHub stars and an active community. It unlocks the full developer loop: build, run, debug, interact, and verify, allowing users to stay in their preferred agentic development environment.

Watching everything is watching nothing: Sampling strategy for Sentry

In a high-traffic production environment, telemetry is your most direct link to the user experience. Every Span, Trace, Log, and Replay sent to Sentry gives you high-fidelity visibility into what is actually happening in production. But to extract the most value out of that visibility, you have to know how to filter signal from noise.

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

TL;DR - Turbopack became the default in Next.js, so we reworked our SDK to stop depending on bundlers. The result is less code, faster builds, and the same telemetry. This blog explains how we got there. You know the feeling when you spend years building tooling that supports something and all of a sudden that something becomes deprecated and you have to rethink your full approach?

Log Drains Now Available: Bringing Your Platform Logs Directly Into Sentry

Sentry now supports log drains, making it easy to forward logs into Sentry without any application code changes or manual project-key lookups needed. If your logs already exist somewhere else, you can now see them alongside errors and traces in Sentry, no code changes required. Already want to get started? The quickstart guide is one click away.

Seer: debug with AI at every stage of development

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

Monitoring microservices and distributed systems with Sentry

If you’ve ever tried to debug a request that touched five services, a queue, and a database you don’t own, you already know why monitoring distributed systems is hard. Logs live in different places, requests disappear halfway through a flow, and when something breaks in production, you’re reconstructing what happened from fragments. Microservices make this worse by design. A single request fans out across small, independently deployed services, often communicating asynchronously.

Green dashboards, red flags

A VP of Engineering (from a company I’m not allowed to name) told me recently: "You helped us find and fix real user-facing issues. Now we need to convince our CTO why that matters more than the standard SLO’s and systems." Here's the thing: your CTO is not wrong in measuring the systems and basic uptime. That’s the baseline though. They’re all trying to watch everything, but they’re seeing nothing as it relates to users.