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.

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.

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.

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.