Operations | Monitoring | ITSM | DevOps | Cloud

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 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.

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.

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.

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.

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.

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: Click to Copy 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?

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.

This is a story about an engineer’s night that could have been bad, but ended up… not so bad. A few weeks ago, on a Saturday, our AI debugger, Seer, started failing. Note the big scary spike on the right. The errors were generic failures from the LLM calls, nothing that pointed at a root cause. Most of the team wasn’t scheduled to be on this weekend, and it just so happened Indragie, our Head of AI, was online. He started paging engineers.

In January 2024, I wrote about removing all advertising cookies and user tracking from sentry.io. It was eight months into the decision at the time, and we were still figuring out what broke and what surprised us. That post struck a nerve: it became one of the most-read things we’ve ever published, probably because everyone building or running a product on the web was watching the same cookie deprecation timeline and wondering what would actually happen if someone just ripped the bandaid off.