When we speak to our customers, one of the most common reasons they say they made the move towards feature flags was the need to make sure their releases didn’t cause more errors for their users. By leveraging feature flags to ramp the release of their features to just small subsets of their users at first, they’re able to see more easily if there is any impact on internal and friendly beta users before starting a larger rollout. However, this becomes a much tougher problem at scale as they struggled to closely watch for errors across all their customers at once. In other words, the issue came down to the fact that the power of ramped rollouts with feature flags was incomplete without the ability to match the error data from their users with the variant of the feature that each user was served.
An Exception-al Integration with Sentry
To that end, we’re excited to announce today the release of a new integration with Sentry to bring their error data directly into Split. Developers use Sentry to capture and process exceptions in the code, exceptions that often reveal user-facing errors. We have been using Sentry internally at Split for quite a while and love how simple it is to have a central place where we can capture the errors that occur across every level of our stack.
Sentry has SDKs in over ten different languages that will automatically listen for and capture errors occurring on a website, service, or mobile app. In addition, Sentry has powerful grouping algorithms to automatically group together similar errors to make it easier to find root cause and debug quickly.
Finding the errors in your latest release
With this integration with Sentry, our customers will now be able to automatically send all exceptions that Sentry captures across the stack directly to Split, to be used with our Impressions. This will allow our customers to define metrics in Split such as the average number of errors that each user is experiencing and have that metric measured automatically across every feature they roll out as well as define alert policies to be notified if error rates increase. Split will compare the features each user is exposed to with the errors each user hits in order to determine which feature in your release is good, and which is rotten.
By measuring these metrics in Split, our customers will now be able to get automatic feedback whenever a feature that has been released, for example, to just five percent of their user base, is causing a degradation for that small subset of users. We’re excited to see the impact this integration has for our customers and their ability to truly measure and mitigate the risk tied to any feature release.
Getting started with Split and Sentry
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
At Split, we know feature flags and data are key to serving the evolving needs of today’s modern consumer. Companies must deliver new features safer and faster while also leveraging all their data to measure whether each feature is actually meeting customer needs. However, when you have data coming in…
A kill switch is a tool that allows anyone on your team to turn off a feature in production with the click of a button. For example, let’s say you have a new banner on your e-commerce site informing users of free shipping. After you release it to production, you…
Feature flags can give your team the ability to release faster and more confidently. However, like so many things in software development, the added stress of maintaining feature flags can overwhelm teams and stop them from exercising best practices. The best way to make sure you effectively and consistently manage…