One of Sentry’s most-trafficked pages is our issue details page, as it helps our customers understand the root cause an error. For those of you who are new to Sentry, we define an issue as a group of similar events. To render the issue details, a significant amount of data needs to be fetched — counts, charts, event details, and other metadata. The two main components on this page are the latest event, and summary statistics.
This month we’re updating several of our mobile SDKs. You might think it’s madness… Mobile March Madness. First up is Flutter. It’s fair to say that all of us have had a bad mobile experience which frustrated us enough to warrant switching apps. Getting the experience right requires a lot of work due to the variety of OSes, screen sizes and orientations.
In January we brought Release Health to JavaScript. This month we’ve been thinking about the overall experience for JavaScript developers, some could call it JavaScript Jebruary. Think back to your last frustrating experience. It was probably caused by slow page loads or getting dizzy from staring at the ever-ending spinner. One survey showed that the average desktop load time on a webpage was 10.3 seconds and on mobile, it was 27.3 seconds.
In the software lifecycle, you need to know what is affecting the customer from your frontend code to your underlying infrastructure. However, no one to date has solved for monitoring the health of software code vs. systems at the level that we have taken on — or at the scale that our customers require, as everything from grocery shopping to gaming is now digital.
Everyone’s software crashes. As an engineer, you don’t feel your users’ frustration unless they reach out to customer support, write bad reviews, or tweet about it. This feedback is often lacking relevant information to resolve the issue. In some cases, you can re-engage with the customer, but that process is time-consuming and inefficient. Another option would be to examine the crash reports, but sometimes they don’t give sufficient insight to fix the problem.
Documentation is a roadmap. It gives us the safest route to reliable, performant code. And just as maps are updated to reflect changing infrastructure, we update our documentation to give you the best way to purposefully use Sentry. In our latest edition of Dogfooding Chronicles, we use Discover to root out the bane of all companies everywhere: the 404 page.
Successful businesses don’t sort data — they shape it. Discover, Sentry’s query builder, gives form to your event data so you can measure performance and trace issues across all your projects. Here’s how.
In a previous life as an Android developer, a customer reported a nasty bug that we didn’t know how to fix. After what felt like countless hours of debugging and writing back and forth to customer support, our only option left was to get our hands on the users’ local database. However, for a variety of reasons, we couldn’t ask the customer to root the device, copy the database, and send it to us.
It’s January 2021 and you’ve probably broken five out of six New Year’s Resolutions. I don’t want to be the reason for breaking your last one, so I’ll cut right to the chase. We just released an update to our JavaScript SDK with the ability to track the health of your releases and support for Web Assembly. Still with me? Great.
In order to continuously improve your Ruby application, you need to understand everything your code touches. That means visibility into how your frontend responds to the database queries that are central to your Ruby application. Sentry’s new Ruby SDK collects and monitors the data surrounding your traces, logs, and key metrics. With it, you now have the context to connect backend issues to frontend performance.
