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.
Split manages more than 50 billion feature flags changes around the world every day. A recent study shows that about 5 to 6% of feature flags are rolled-back (or killed, using Split terminology in reference to a kill switch) within 30 days of being created. This speaks to the importance…
At Split we believe in the power of metrics, and are always striving to improve the ways we help our users make more data-driven product decisions. In this previous post we talked about the importance of understanding the impact of a new feature release via key and guardrail metrics. With…
Find faulty features before your customers do One of the most common reasons, our customers tell us, for moving towards feature flags is risk mitigation: the need to make sure releases don’t cause errors for users. Given how frequently organizations are now deploying features, the ability to limit the blast…