Sentry started life in 2008 as an unlicensed, 71-line Django plugin. The next year we began publishing it under BSD-3, and ten years later we switched to the Business Source License (BSL or BUSL). Last year we purchased Codecov, and a few months ago we published it under BSL/BUSL as well. That led to some vigorous debate because of our use of the term “Open Source” to describe Codecov, from which emerged this helpful suggestion from Adam Jacob, co-founder of Chef.

It seems like these days there’s a new exciting framework or dev tool launched every week. The challenge is that even if you’re ready and able to use new products, your existing tooling might not be up to the task; it could be months or years before your developer tools add support for the burgeoning platforms you want to use.

I know, we’re Sentry the error and performance monitoring platform and we catch production issues. But as you (hopefully) saw during our Launch Week announcement, some broken experiences simply won’t throw an exception. So we built a way to detect when your users are slamming their keys on the keyboard in frustration, and to even let them contact you directly when that doesn’t go their way.

Extracting relevant insights from your performance monitoring tool can be frustrating. You often get back more data than you need, making it difficult to connect that data back to the code you wrote. Sentry’s Performance monitoring product lets you cut through the noise by detecting real problems, then quickly takes you to the exact line of code responsible. The outcome: Less noise, more actionable results.

Since 2020, I’ve been working on an Express (Node.js framework) application to power viewer interactions and events that happen whilst I’m streaming live coding on Twitch — my Twitch bot. Since using Sentry for error monitoring and crashes using the Sentry Node SDK, I’ve already squashed quite a few bugs that were entirely a result of my own terrible code.

Beautiful syntax-highlighted GraphQL errors are coming — get ‘em while they’re fresh! Not that we encourage you to add more errors of any kind to your code. But if you do, they’ll now look so much better in Sentry.

Your app’s networking directly affects the user experience of your app. Imagine having to wait a few seconds for the page to load. Or even worse, imagine waiting for a few seconds every time you perform an action. It would be infuriating! Before you go on a fixing adventure, it’s a good idea to understand what causes that waiting time. So let’s do that!

Hey, you. Yes, you. Do you want to fix broken code faster and easier? Of course, you do. Who doesn’t? Well, lucky for you, we dedicated the whole month of October (and every other month) to helping you do just that. Checkout what’s new from Sentry and our friends at Codecov.

It’s official, summer is over. So grab yourself a pumpkin-spiced food item of choice and check out what the Sentry team has been up to this past month. From introducing new features, product improvements, and integrations, we can objectively say we made Sentry at least a smidge better this month. Keep reading to see how the latest developments can make your debugging experience less painful.

Render-blocking resources are JavaScript and CSS files that prevent the web page from loading until they are downloaded. These might be critical resources that don’t get loaded immediately, or non-critical resources that are being loaded at the very beginning. Fixing render-blocking JavaScript and CSS helps improve page load times so sneakerheads don’t bounce to your competitor’s site while waiting for the images of the latest drop to load.