Operations | Monitoring | ITSM | DevOps | Cloud

As developers, we know that debugging can be a time-consuming process. Hunting down elusive bugs or trying to reproduce an issue based on vague user reports can turn a simple fix into an hours-long journey. While leveraging logs, metrics, and tracing to reproduce locally or try to understand what happened can help us identify a root case, we’re often missing a critical component to truly being able to understand the impact on our users.

Given that 100% of the databases I have interacted with in my professional career have been SQL databases, my data-based mental model (please enjoy my pun) has always defaulted to a relational one. However, when spinning up a tiny side project in 2020 (a bot to provide interactivity to my Twitch stream), my data-storing requirements didn’t call for a relational model at the time, so I chose a NoSQL solution: MongoDB.

This is a guest post from Simon Grimm, creator of Galaxies.dev, where Simon helps developers learn React Native through fast-paced courses and personal support. Debugging React Native apps has traditionally been a bit of a pain. Developers usually ranked debugging as their biggest pain point of React Native, which, as we all know, makes up quite a lot of development time. But the good news is that things are getting better.

TTFB (Time to First Byte) is a commonly used metric that measures the duration between a client's HTTP request and the receipt of the first byte of the server's response. A lower TTFB means a more responsive server and faster page load times. In the past few years in the web dev world, we’ve seen a significant push towards rendering our websites on the server. Doing so is better for SEO and performs better on low-powered devices, but one thing we had to sacrifice is TTFB.

We’re expanding beyond just code coverage and added a suite of new capabilities to help you break production less: AI PR Review, AI Test Generation, Test Analytics, and Bundle Analysis.

Optimizing app performance can be challenging, even for seasoned developers. Frontends groan under the weight of bloated assets, backends lag from sluggish database queries, and mobile screens freeze at the worst times. But it doesn’t have to be that way. Sentry’s latest update brings domain-specific views to Insights & Profiling, giving developers the clarity they need to solve issues quickly.

What if you could not only find software issues you care about but also have the fix ready? We just introduced several updates that intelligently group new issues, reducing noise by about 40% and automatically suggesting fixes to annoying bugs you shouldn’t have to think about.

Whether it’s sitting through a meeting that should’ve been an email or reading a blog post written by AI – no one enjoys losing time they’ll never get back. That’s why we rolled out updates to help you fix problems faster while skipping the manual grind, including smarter search, customizable issue views, real-time uptime alerts, and Session Replay for Mobile.

The Sentry Unity SDK has been effective for crash reporting, including: We are confident that we have the best crash-reporting solution out there. Now we were looking towards offering some out-of-the-box insights into the game’s performance. Right out of the gate, we hit the first question: What would auto-instrumentation for Unity games look like?

This post is part of our debugging series, where we share tricky challenges and solutions while building Sentry. On March 4th, 2024, the most metal incident happened - INC-666 INC-666, in a nutshell, was where the issue alert rule post-processing step was flooded with more load than it could handle, and alerts that were supposed to have fired did not. This means that Sentry customers might not be receiving alerts if the query that would have triggered the alert is rate-limited.