Operations | Monitoring | ITSM | DevOps | Cloud

Two years ago, Sentry built a metrics product that worked great on paper. But when we dogfooded it, we realized it was not what our customers really needed. Two weeks before launch, we killed the whole thing. Here’s what we learned, why classical time-series metrics break down for debugging modern applications, and how we rebuilt the system from scratch.

Developers don’t need another “run this tool, stare at a number, and feel bad about it” website. So we built something different. WebVitals helps you analyze, optimize, and ship faster websites, all in one place. Built by the same folks who obsess over stack traces and slow queries, it connects the dots between performance metrics and what’s actually slowing your users down. In one place, you can.

As you may have noticed, Sentry just got a major glow-up. For too long our product looked like boring enterprise software, while our brand screamed bold and irreverent. No more. From this moment forward our product now matches the vibe you’ve come to expect from us. The result is something that’s more vibrant, more tactile, and more Sentry. Welcome to the S.C.R.A.P.S.

Previously, I wrote about how debugging, whether done by humans or AI powered tools, depends on context. Without it, even the most capable systems can only tell you what code is broken, but not why it broke. Now that AI can access the same depth of context developers rely on (stack traces, traces, logs, commits, and code), the way we build and operate software is changing. We’re moving from an era of monitoring to one of reasoning.

Some of the team at Sentry spent this past quarter fixing bugs, more than 800 to be exact. Among them was a complex issue causing transaction spikes in our own Sentry project. Using Sentry Logs, we were able to investigate, trace the root cause, and resolve the problem.

We shipped an improvement to Sentry's game engine and native SDKs that most developers probably didn’t even notice until now – unless they were explicitly aiming to test their Windows-built games on Linux with Wine/Proton compatibility layers. That's exactly the point. While we were focused on improving our game engine SDKs, our learnings while investigating a mysterious issue are applicable for any Windows application running on Linux via Wine or compatibility layer.

Last month, we launched AI Code Review, our developer tool that automatically catches bugs, finds performance issues, and helps you ship PRs faster. 30 days later, here's what’s new.

With the first major release of the Sentry Unreal SDK (now on v1.2.0, and you can also explore in our interactive sandbox), we’ve made some important improvements to support cross-platform Unreal developers when it comes to platform coverage, debugging with user feedback, and performance monitoring improvements. Here’s what’s new.

Browser tracing has always been one of those things that feels invisible until it isn’t. When it works well, you get clear, actionable insights into how your app is performing in the wild. When it doesn’t, you’re left staring at noisy data, gaps in traces, and spans that don’t quite tell the story. Over the last few months, we’ve been chipping away at that problem.

I have begun to truly embrace vibe coding over the last few months, using Cursor as my main code editor and Claude Sonnet 4 for my agent's LLM. It's an exciting time as a developer, we get to experiment with something that promises to 100x our productivity while pioneering the new workflows and strategies for implementing these tools. But, as most people who have done any extensive development with LLMs in a sufficiently sized code base knows, it's a bit like trying to herd scared cats.