Kill switches with feature flags: how to

Software kill switches provide an immediate response mechanism to mitigate risks, maintain system stability, and ensure a seamless user experience. They enhance stability, reduce downtime, and enable real-time control over feature availability.

In this post, we’ll explain how kill switches can be implemented to change release features and implement dependent features.

What are kill switches?

In a nutshell, kill switches are a safety mechanism used to shut off machinery in an emergency. They’re usually activated when the machinery can’t be shut down like normal.

Here’s how it works in a development context: Many large sites occasionally have some features that struggle under certain edge cases. This often comes from third-party integrations. Typical use case: One of a site’s payment providers is down and can’t take new orders.

Kill switches makes it super easy to turn these flaky features off. They’re a simple way to degrade a service in order to keep your business running.

“Of course, it would be nice to not need the kill switches, but they have proven their value over time.”

Senior developer, FINN.no

 

Kill switch vs. feature flag

A kill switch and a feature flag both provide control over software features, but they serve different purposes. A kill switch is a safety mechanism designed to immediately disable a feature in critical situations, while a feature flag is a more versatile tool used to toggle features on or off during development or deployment.

Feature flags can also function as kill switches, offering the same instant deactivation capability. By using a feature flag as a kill switch, teams can quickly address performance issues, security concerns, or unexpected bugs without requiring a redeployment.

Kill switch vs. feature flag: examples

For review, this is what a release flag looks like in code: 

if (unleash.isEnabled(“AwesomeFeature”)) {

  // do new, flashy thing

}

 

Anyway, what happens if your feature is fully released, but you need a way to disable the feature at any point? This is what a kill switch is for. This is what a kill switch looks like in code:

if (!unleash.isEnabled(“AwesomeFeatureKillSwitch”)) {

  // do new, flashy thing

}

 

Notice the ! and the new name. This communicates that if a feature flag is not enabled, then proceed with the feature execution change.

H2 – How does a kill switch work?

A good general practice is to wrap your flaky feature in a dependent feature flag. Your application should assume that the feature is working as expected so long as the feature flag is disabled. Here’s what it looks like in Unleash:

The feature flag is disabled when everything is working as expected. When you disable a flag by default, your application will still have the feature enabled. This is in case it can’t fetch the latest version of the feature flag.

If you detect any problems with the integration, you can then easily turn on the kill switch. The feature will then turn off the feature flag. When the kill switch is enabled, users will not see the flaky feature.

Why use kill switches?

Kill switches are essential tools for ensuring system stability and minimizing downtime during unexpected issues. They allow teams to instantly disable problematic features, mitigating risks without requiring code redeployment.

Beyond emergencies, kill switches are versatile and can support other use cases. For example:

• A/B Testing
  Kill switches can deactivate test variations that underperform or cause issues, ensuring experiments don’t disrupt the user experience.
• Canary Releases/Progressive Rollouts
  In phased rollouts, kill switches provide a safety net, allowing teams to halt new feature deployments if issues arise in specific user groups.
• Network Load Management
  Kill switches can reduce traffic or disable resource-intensive features during high-load periods to maintain system performance. 
• Incident Management
  During incidents, kill switches offer an immediate response to isolate and resolve critical problems, minimizing impact on users.

Changing a release feature flag to a kill switch

Changing a flag from “Release” type to “Kill switch” is a bit different from simply setting up a kill switch.

In this case, we’re taking a pre-existing flag and making it do something new. Basically, we wanted the flag to stop a thing instead of activating it. 

Challenges

There are a few challenges when changing feature flag types:

• First, you’ll need to keep the kill switch enabled, because your code treats it as a release flag (remember the code change above). This means that inside the Unleash admin, the UI can be a bit misleading. Having the kill switch enabled keeps your feature on, instead of killing your feature. Weird and unhelpful.
• Second, your code would, in fact, be evaluating a kill switch, not acting as a kill switch. A distracted developer might think something’s wrong, then rewrite the code to make it look more like a kill switch. 

Pretty much things get super confusing when you don’t change the name and code. Also consider that you’d need to coordinate the changes with a deployment. Otherwise you’d temporarily disable a launched feature.

Implementing dependent feature flags as kill switches

Here’s the alternative: using a dependent feature flag as a kill switch.

Use the clone feature functionality in the Unleash admin to create a clone of our feature. The cloned feature keeps the same configuration as the original feature. This means the feature kept the same release strategies, segments, and constraints. What we change are the operators, in that we inverted them. NOT_IN replaced IN, and NUM_GTE replaced NUM_LT.

This left us with two flags. When one flag was enabled, the other disabled, and vice versa. Using dependent feature flags could make this setup super simple. With these two flags, we could safely change the code. The old version would use the feature flag while the new version would use the kill switch. 

Best practices when using kill switches

It’s pretty simple to use feature flags to introduce kill switches into your service.

Still, it’s important to keep the number of long-lived kill switches to a minimum. You should treat them as a powerful tool to manually degrade your service by turning off non-critical features during high load.

The Unleash approach to feature flags

Feature flags enable development teams to manage features in a dynamic, flexible, and controlled manner. Like any tool, you need to use them the right way—you don’t want to build a spaceship out of bricks.

Unlike proprietary software where users are bound to the product roadmap determined by the company (and its shareholders), an open-source feature management system allows you to modify and improve the software based on your specific use cases. Our users are not bound or dependent on the limitations of our code.

Unleash open source is available as a docker container, or click-to-deploy in Heroku and Digital Ocean. Choose your preferred deployment and get started in minutes.

While there are other proprietary tools such as LaunchDarkly, we believe there are a lot of benefits to using an open-source system like ours. See for yourself.

Want to try out Unleash?

GET STARTED

TRY OUR DEMO