Operations | Monitoring | ITSM | DevOps | Cloud

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.

We got a little behind on updating our changeLOG, so we’re dumping it all into this bLOG post instead. Think of it as one giant, retroactive changelog entry or, if you want to be dramatic about it, one massive prompt injection straight into your feed. Either way: here’s everything that shipped for Sentry Logs this summer. Would you rather listen to the team talk about what they built? Check out this video where Kyle and Josh talk about the latest updates on Logs.

AI is going to generate a lot of code from here on out, and a lot of bugs along with it. You already know this. We’ve talked about it before. The bigger challenge is making sure you don’t spend all your time fixing the broken code your agents write. You’re going to need a system that makes it easier to fix those issues for you and fortunately, there are a lot of solutions out there for building automated workflows.

You can already send OTel traces to Sentry. Point your OTLP exporter at Sentry’s endpoint, set environment variables, and your spans show up in the trace explorer. Our OTLP setup guide and “You Don’t Need to Pick One” walk you through that. But those spans are islands. You get a trace waterfall in Sentry, sure.

You know the drill: a crash report lands in your queue with a pristine stack trace pointing at some innocent-looking function and absolutely no clue about what the player was actually doing. Were they mid-boss-fight? Alt-tabbing during a loading screen? Standing perfectly still in the tutorial? QA can’t repro it, the player’s bug report says “game crashed lol,” and you’re left staring at a callstack playing twenty questions with a core dump.