Operations | Monitoring | ITSM | DevOps | Cloud

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.

During a recent Agent Hackweek, an internal Sentry event that gives us a week to build any AI or agent project we want, a colleague pitched me on writing the Laravel AI integration. The goal was to give agents built with Laravel AI the same Agent Tracing support we already have for other frameworks. I liked the idea, he built Sentry’s Agent Tracing for Python based agents before which meant he already had domain knowledge.

In order for users to get the most out of the data being sent to Sentry, it’s important that we make it easy to find that data. Our team works on features to help users browse their data to find a particular event using search queries and filters. The search bar enables users to find their data by specifying search terms. Searching uses the Sentry Search Syntax, which can be barrier for users.

There’s a very specific kind of frustration that comes from waiting several minutes for a video to encode, dragging it into a message, and getting hit with a “file too large” error. Then you’re blindly trying to shave off a few more megabytes by re-encoding, maybe at a lower resolution or a smaller bitrate, hoping you won’t have to do it more than one or two more times. Here’s how I used Sentry’s Application Metrics to make a more accurate video size estimator.

This post and its code examples focus on the JavaScript SDKs. If you’re on another platform, it’s still worth reading to understand why we made the change and what’s coming your way. We’re replacing the boolean sendDefaultPii with a new option called dataCollection. The old switch was all or nothing: turn it on and you got everything, leave it off and you got only a fraction.

Session replay software lets you see exactly what your users saw without having to pull a Freaky Friday with your customer. The question is: which tool actually delivers on that for your team, your stack, and your regulatory environment?

Every morning, before anyone on the team has looked at a dashboard, a Claude Routine has already read around 800 of the previous night’s conversations from Seer, Sentry’s AI agent for triaging and fixing errors. It flags the ones that look broken, and files tickets for anything new. By the time we sit down with coffee, the triage is mostly done.