Operations | Monitoring | ITSM | DevOps | Cloud

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.

No matter your business, keeping customer data secure is critical toward keeping your customer’s trust. With the rise in data breaches (and subsequent security certifications), we don’t have to tell you why you should scrutinize every cloud service that you consider — including us. To that end, we believe in being explicit with our compliance. And that includes how we pursue independent certifications like ISO, HIPAA, and now, SOC 2 Type II.

Slow is the new downtime. What you once feared from a downed website — decreased conversion rates, lower page ranks, abandoned carts — now applies to a slow-loading experience. Problem is, slow is more nuanced than downtime; that is, while downtime is binary — the site’s either up or it isn’t — slow is in the eye of its beholder. It’s why asking what makes a slow website gets the same shrug from a developer as asking them how long an afternoon is.

Performance monitoring is great because it lets you see whether your application is fast or slow, and which parts need speeding up. For Node developers, those “parts” are most often endpoints handling incoming requests. Since the introduction of our performance monitoring offering in July 2020, Node devs have been able to use the Sentry SDK, @sentry/node, to measure the total time it takes to process each request, but we made some significant improvements since then.

To us, dogfooding means using Sentry to improve Sentry. Here in this article, you’ll see how we used Performance to improve our search infrastructure. Recently, we extended our performance monitoring solution support to PHP and Serverless. We’re bringing it to Ruby and Java + Springboot soon too. But as some of you may have noticed, there’s also a new view in Performance, Trends. Trends shows you the most improved and regressed transactions in relation to releases.

To improve front-end performance in your application, it’s important to understand what kind of problems users are experiencing. They may be encountering slow load times, seeing unexpected shifts, or having trouble interacting with UI components. The question is, how bad is it? Is it perpetual-rage-click bad? Is it ditch-your-app bad? Is it rant-on-Twitter bad?

Sentry is excellent at capturing runtime errors in your applications. With the recent additions of performance monitoring and release health, it can further help as you build and ship code. Recently we used Sentry to ensure we didn’t break Sentry while doing a large refactor. When replacing an API or code path with a new implementation you’ll likely ‘deprecate’ the old path, but how do you know when that old path is finally not in use?