Operations | Monitoring | ITSM | DevOps | Cloud

When a JavaScript error reaches Sentry, the stack trace points at minified code. Sentry finds the source map that was uploaded for that build to be able to show you the original file and line. Source maps are uploaded in artifact bundles. There are two ways to find the right one: Symbolicator, our open-source symbolication service, does the lookup when it processes an event.

For the last few weeks I’ve used a coding agent to find and fix backend performance issues in Sentry, starting from the traces Sentry sends to itself. Most of the fixes only changed a line or two. But together, they removed hundreds of millions of queries a week, and some expensive lookups became hundreds or thousands of times faster (more details on that below).

Starting with Sentry Android SDK 8.51.0, profiling on Android 15+ devices is powered by Perfetto, through Android’s system ProfilingManager API. That means fewer legacy tracer crashes, lower CPU and memory overhead, and more representative profiles. You don’t need to change any configuration: if you already use continuous profiling, devices on Android 15 and newer pick up the new profiler as soon as you upgrade.

If we were to reduce web performance into a single term, it would be “web vitals”. Web vitals are a universal signal that every developer can measure, and more importantly, optimize for. They describe many facets of the user experience when it comes to performance, but they were limited to specific types of navigations. Capturing web vitals for your apps has been largely about users landing on your site from somewhere else. We measured that experience and you optimized for it.

AI-powered apps are hard to debug without observability. From one run to another, AI produces different results, goes down different paths, and you’re none the wiser as to why it’s happening. Agent Tracing bridges the gap between prompt, tool calls and final output, all within the context of your app. If things break (it always does at some point, we know from experience), you get everything in one complete trace.

This is a guest post from Armin Ulrich, a fullstack developer, and founder of placid.app. He also created the MadeWith* network where he shares his projects and allows other developers to share theirs. Two people and one beagle run the project showcase madewithvuejs.com. The beagle is actually an AI agent that we have added to our workflows, but we’re very fond of her by now. Milly is part of the team, scouting for content, building features and sniffing for bugs.

Since Sentry added Logs and Application Metrics, there are now two ways to record that something happened in your app, and they can look pretty similar: Sentry.logger.info("user.signup") versus Sentry.metrics.count("user.signup"). Both store attributes, both include shared context automatically, and both can be filtered, grouped, and counted. So when you’re instrumenting your code, which one do you reach for?

The title is not a joke. For those of you who know Sentry, you know we’ve been giving back to Open Source maintainers since our early days in whatever ways we could. But around five years ago we really started to give in a more meaningful way. This year we increased our budget from $750,000 to $1,000,000.

Our team has been working hard over the last quarter to make sure Sentry’s Android SDK is faster for you. During this time, we reduced the Android SDK init time by 20-30%. We also reduced memory allocation, fixed memory leaks, and reduced background CPU time by up to 10%.

Sentry’s Flutter SDK 10.0 makes streaming traces the default and changes how unhandled Flutter errors affect Release Health. Errors that leave your app running no longer mark the session as crashed, so your crash-free rate better reflects actual app crashes. The release also gives app startup its own trace on Android and iOS, simplifies logs and metrics setup, expands Dio network error capture, and respects Flutter’s sensitive-content markings in Replay and screenshots.