What is Flag Trigger or Auto-Kill Webhook?
A flag trigger or auto-kill webhook is a feature or component of a software system, particularly in the context of automation and web development, designed to change the state of a feature flag based on predefined conditions or triggers.
A webhook is a mechanism that allows one system to notify another system of events or updates in real-time. It typically involves sending HTTP POST requests containing event data from one application (the sender) to another application (the receiver) when specific actions occur.
An auto-kill webhook that turns a feature flag “on” or “off” accomplishes the same goal as using an API call to perform this task, except that it does not require authentication and it can be expressed as a single string in the form of a URL. In the place of authentication, an auto-kill webhook uses what’s known as an “unguessable URL” that is presented only once when the webhook is created. This is similar to an API authentication token but it’s built into the URL itself. The administrator creating the auto-kill webhook must capture and store this URL in a local repository, as it’s not possible to retrieve the URL from the feature flag system later.
A URL that acts as a switch
It’s important to not read too much into the phrase “auto-kill” or “flag trigger” because the webhook itself doesn’t know when to trigger, but rather always just flips a particular flag to one state or the other (typically “on” or “off”). An auto-kill webhook is therefore merely a remote switch. It’s up to the system that calls the webhook to decide whether flipping that switch is appropriate and safe.
Flag triggers are called from external monitoring systems
Flag triggers are usually called from external monitoring systems, such as Datadog or Dynatrace. This is accomplished by setting an alert threshold in those systems that calls the webhook when the criteria is met, much the same way those systems might send a notification to the engineer on call. The challenge is to know which flag needs changing under what circumstances, which requires administrators to configure monitoring and thresholds (and create auto-kill webhooks) specific to each flag.
Configuring monitoring and thresholds specific to each feature flag in an external monitoring system can be challenging; the administrator must know know what functionality each flag controls (known typically by the developer who implemented the flag), which specific telemetry signals the system creates that are relevant to that flag, and under which conditions it is safe to take automated action via an auto-kill webhook. Since this process must be repeated for each flag before that flag is rolled out to production, it’s likely you’ll need to be very selective about where you will use this approach.
Native monitoring and triage may be a more scalable choice
An alternative approach is to have the feature flagging platform watching the telemetry and making the decisions about which flags need to be switched and under what circumstances. Split’s Feature Data Platform combines feature delivery and control with feature measurement and learning, without requiring per-flag configuration to decide which metrics to associate with each flag. Split watches all metrics during every progressive delivery rollout and is able to determine on its own which metrics are being negatively impacted by a rollout in progress. Split’s approach is called Instant Feature Impact Detection (IFID).
