If you have a large codebase with multiple developers shipping quickly – errors need to be caught quickly as well. To help ensure your code is performant and reliable while you’re deploying code, we partnered with GitHub to build a bridge between your CI/CD workflow and your favorite error monitoring tool (Sentry, of course).
Today we’re announcing our new Spend Allocation feature and updates to Spike Protection, giving you more control over how your projects consume events. While we’ve made it super easy for teams to add Sentry to their projects, we kept hearing from the community that they wanted more guardrails to ensure their noisy projects don’t eat through their event quota.
Today is a special day at Sentry, as today we welcome Syntax to the family. We’ve long been fans of Scott and Wes, of what they’ve built with Syntax, and of their general curiosity, drive, and hustle. As one of Sentry’s earliest partners, it’s been amazing to watch and experience their growth alongside our own. Today we’re going to talk about the next chapter of Syntax, one with increasing ambition, and one we hope you’ll be just as excited about as we are.
I’m Jerrod, the Head of Codecov @ Sentry. I’d like to share updates from the first major release of our Codecov and Sentry integration and new Codecov pricing for Sentry customers.
Code Mappings connect errors to the source code in a repository. And since errors can have paths that are different from the tree structure of the repository, Code Mappings determines the accurate path through a combination of a repository URL and a path transformation. Sentry uses Code Mappings to serve issue context on the issue details page.
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.
