A toggle, in computing, is any item that can be flipped between two opposing states. This includes everything from the switches in our caps lock to cordlock toggles for stopping a drawstring.

In the world of user interfaces toggles can be used to enable or disable behaviors on a web page or app. They can also be used to show or hide content based on certain conditions, such as when a button is clicked.

Toggle configuration, when properly managed, can be very powerful. It can be used to re-configure a single instance of a service or a set of instances without having to deploy code into production.

This ability to re-configure feature flags at runtime can be a great tool, but it must be handled carefully to avoid confusion or worse a need to restart the entire process or application in order to change a toggle’s state.

When used appropriately, toggle configuration can be managed through static files in a central repository or via an API endpoint that exposes dynamic in-memory re-configuration of a specific flag. However, this approach is cumbersome when applied to a large number of feature flags, and can lead to unexpected regressions in a testing environment when a change is made to an existing flag’s configuration.

Savvy teams are careful to remove feature toggles when they are no longer needed. This can be as simple as adding a removal task onto the backlog when a toggle is first introduced or as complex as creating “expiration dates” which will fail a test (or even refuse to start an application!) if a feature flag remains in place after its expiration date.