Operations | Monitoring | ITSM | DevOps | Cloud

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.

This post is about a recent change to the Sentry JavaScript SDKs. If you don’t use Sentry with JavaScript, it may still be useful as a look at how we made the change and why. In the Sentry JavaScript SDK v11, we rebuilt how our tracing integrations work. While we still support the OpenTelemetry standard (described in more detail below), we now instrument your dependencies with a code transformer instead of using the OpenTelemetry instrumentation classes as we did in previous versions.

Our SDK adds work to the app that installs it. It records recent app activity as breadcrumbs and keeps user information and other diagnostic data up to date. Changes to that information are called scope updates. On Android, we send those updates to a worker isolate, which passes them to the Sentry Android SDK. We found that the calling isolate and the worker both normalized the same data. The encoding step also created a JSON string and an extra byte buffer that we could avoid.

Setting up crash reporting is rarely the most exciting part of shipping a game. Paste a DSN, flip a few checkboxes in Project Settings, turn on symbol upload, package a build, crash it on purpose and check that the event shows up in Sentry… It’s not hard to do (and important), but it’s the kind of work you’d happily hand off to someone else. With Unreal Engine 5.8, that someone else can be your coding agent.

I’ve been getting some version of this question a lot lately, mostly in our Seer preview webinars. Different audiences, same handful of questions: Worth answering all three in one place. Honestly, I needed to write this down for myself too. Things are moving fast around all of us and answers seem to get more nuanced by the week. This is an attempt to codify the difference: what each option is and when it makes sense to reach for one over the other.

Most advice about surviving a traffic spike is about capacity. Scale the fleet, warm the caches, load test the checkout path. All of it assumes you can fix whatever breaks the moment you find it. Mobile apps don’t work that way. I spent an hour on a workshop with Jay Henry, a senior engineering manager at Etsy who owns engineering strategy across three teams covering CI, build, test, release, observe, and SRE. Jay’s take: a web team having a bad day can revert in minutes.

Today marks exactly five months since we launched Seer Agent, our friendly AI agent for querying all things in your Sentry projects (well, five months and a day ago, but close enough). Since then, we’ve had a lot of chats with Seer Agent. You may have even seen a few of them popping up on social media recently. It’s become an integral part of our debugging workflows and feature iteration process.

There is a moment every web user knows by feel. You click a link, read the page, hit Back, and the previous screen is just there. No spinner, no flash of white, no jitter. This is the bfcache (back/forward cache) in action, and for most teams it feels invisible.