Find faulty features before your customers do. One of the most common reasons that our customers move 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 radius of a faulty new feature becomes paramount. We found that not only do our customers want early insights into what could go wrong, but should it go wrong, they want to be able to respond to it within minutes. This means careful monitoring of feature releases, followed by alerting based on performance metrics.
One of the biggest successes we’ve had at Split in terms of customer feedback has been our ability to uniquely tie data to features. Showing different variants of a feature to different users means that every feature becomes an experiment. Tying each variant of the feature to user event data means that our customers can have early insights into the success of a feature. This in turn means greater confidence in rolling out the variant of a feature with the greatest likelihood of improving customer experience.
Tying data to features allows our customers to delight their customers better. Recently we asked ourselves what other data and functionality could enable our customers to serve their customers even better.
Introducing Feature Monitoring
For example, if your page load times get worse or your error rates rise, even for just 5% of your end users, as a result of recent change, Feature Monitoring can help you find the feature at fault before your customers do. Speaking more broadly, that means fewer rollbacks or hotfixes and greater confidence to move fast with no downtime.
We are very excited to demonstrate our Feature Monitoring solution in greater detail. Watch a one-minute video covering the three key benefits of Feature Monitoring:
Stay up to date
Don’t miss out! Subscribe to our digest to get the latest about feature flags, continuous delivery, experimentation, and more.
Continuous integration, continuous delivery, and continuous deployment are foundational in today’s agile engineering ecosystem. However, many times they are used interchangeably and often incorrectly. Let’s remove the confusion and settle the differences between continuous integration, continuous delivery, and continuous deployment. What is Continuous Integration? Continuous integration happens when developers regularly…
SRE goals align perfectly with robust feature delivery and experimentation, where every new feature gets tested, and releases happen behind feature flags.
Engineers are deploying half-finished features into production, and they’re doing it on purpose. They use feature flags to hide their partially completed work. You can too.