How your code performs isn’t a subjective debate. Well, at least not anymore — in the past few months, Sentry has started telling you exactly what’s slow and where to fix it — specifically, N+1 database queries in your code. While we’ve all had to fix an N+1 problem, performance problems come in multiple flavors. Today, you’ll notice more Performance Issues in your issue feed, Slack alerts, and email notifications.
The observability landscape - specifically your traditional Application Performance Monitoring (APM) offerings are failing modern-day developers. These legacy tools are made for ops and infra teams to keep their infrastructure and services up and running. But when it comes to helping the people that actually write the code to find and fix latency issues, these tools - which often come with massive price tags - leave developers hunting for issues causing slowdowns.
I, like many of you no doubt reading this, am an engineer with very strong opinions on how software should work. I am not interested in moving fast and breaking things; I am not interested in changing the world. I am interested in building pleasant, ergonomic software and charging money for it. My company, Buttondown, was born from that ethos.
A Sentaur who uses Sentry to build Sentry wanted to know where a specific service associated with an issue was being hosted in our cloud environment. This prompted us to create a new cloud data gathering feature for our Python SDK, which is available to everyone now, and not just Sentaurs.
At Sentry, we practice continuous delivery, which means that code can be released as soon as it’s merged into the main branch. This allows us to iterate quickly on our product, making new features, bug fixes, configuration changes, and experiments available in production as frequently as possible. We merge over 700 pull requests a month.
As an open source company that grew out of a side project in 2008 to an application and performance monitoring platform (APM) used by over 3.5 million developers, Sentry is committed to open source and the community of developers maintaining and building in the open. Similarly, we take a public approach to building our software, which is why it’s a natural extension of our values to announce our support for OpenTelemetry (or OTel), the leading open standard for observability.
Third-party JavaScript libraries provide developers with the tools they need to build modern web experiences, and a bit of cheatcode at times to not have to start from scratch. I mean, you don’t want to build an entire monitoring solution, so we help with Sentry’s Next.js SDK that only requires a couple of lines of code.
You know that annoying bug? The one that doesn’t show up locally? And no matter how many times you try to recreate the environment you can’t reproduce it? You’ve gone through the breadcrumbs, read through the stack trace, and are now playing detective to piece together support tickets to make sure it’s real. To get to the root cause faster - without rolling your head on your keyboard - we built Session Replay, now generally available for all web-based platforms.
A couple months ago, we launched Profiling in alpha for users on Python and Node.js SDKs — today, we’re moving Profiling for Python and Node.js to beta. Profiling is free to use while in beta — more updates to come when we near GA. Profiling is a critical tool for helping catch performance bottlenecks in your code. Sentry’s profiler gets you down to the exact file/line number in your code that is causing a slow-running query.
The performance of your app matters. From ensuring a good user experience to retaining users, performance makes a difference in your app’s success. Using the right tools can make it easier to ensure your code is meeting your performance goals, before you have to switch to a bigger EC2 instance or users start complaining. One of the best tools in a developer’s toolbox for ensuring good performance is profiling.
