Sentry recently launched Performance Issues, a feature to help developers discover and fix common performance problems in their projects. We tested this project internally and with alpha users, so when we finally turned it on for all Sentry users, we were delighted (and dismayed) to hear from Carlton Gibson, current Django fellow and great human, that Sentry had.
Today we are releasing Dynamic Sampling, available to all new customers, and opt-in for existing customers. This goes beyond a new feature however and is an overhaul to the way we package Sentry’s Performance Monitoring product. We are saying goodbye to the days of static, magic number sampling configured within the SDK and moving to a world of flexibility.
Sentry is an open source company, and it’s important to us to financially support our non-commercial colleagues in the community as we continue to enjoy commercial success. We’ve given money forever, but last year we really got organized and gave $154,999.89 to 108 recipients. Two points make a line, and this year we are back with a continuation of the industry-leading open source funding program we put in place last year.
In the first three parts of this series around improving performance in your Django applications, we focused on database, code optimization, and frontend optimization. In part 4, we will focus on ways to improve the speed of the Django applications.
Sentry Alerts ping you on Slack, Microsoft Teams, or Pager Duty when something goes needs your attention. However, too many alerts can turn your notification channel into an endless noise feed. I spoke with dozens of Sentry customers in the past 6 months, and something I heard over and over again was “Sentry can get noisy at times” and “There are days I can’t keep up with Sentry notifications because we get so many of them”. Does this sound familiar?