Operations | Monitoring | ITSM | DevOps | Cloud

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?

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.

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.

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.

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

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

Logs are often the first place dev teams look when they investigate an issue. But logs are often added as an afterthought, and developers struggle with the balance of logging too much or too little. As a seasoned developer, you may remember a time when you were asked to investigate an issue and then handed a 200 MB plaintext log file. Three hours and four Python scripts later, you would realize that the problem was in a different component.

Stack traces are great, but they only tell you what broke. They rarely tell you why. When an exception fires, you get a snapshot of the moment things went sideways, but the context leading up to that moment? Gone. That's where logs come in. A well-placed log can be the difference between hours of head-scratching and a five-minute fix. Let me show you what I mean with a real bug I encountered recently.

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

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