After a bad release last week, how can we disable a feature in production instantly without doing a rollback deploy?

When a release goes sideways in production, you don’t want to wait on a rollback deploy—you want a kill switch you can hit in seconds. The way to get there is to treat features as runtime configuration, using feature flags, so you can instantly disable a bad path in production without touching your deployment pipeline.

Quick Answer: Use feature flags as kill switches. Wrap risky functionality in a flag, ship the code, and if something breaks, flip the flag off in LaunchDarkly to instantly disable the feature in production—no rollback deploy, no 2am fire drill.

The Quick Overview

• What It Is: A runtime control pattern that uses feature flags to instantly turn features on or off in production, without redeploying.
• Who It Is For: Engineering, SRE, and product teams that want faster releases, safer rollouts, and an instant escape hatch for bad changes.
• Core Problem Solved: Eliminates the need for emergency rollback deploys by giving you a kill switch you can flip in seconds when a feature misbehaves.

How It Works

Instead of baking feature behavior directly into your code paths, you guard it with a feature flag. That flag is evaluated at runtime by LaunchDarkly’s service. Your application checks the flag before executing the new behavior; if the flag is off, it falls back to the last known-good path. Because flags are evaluated remotely and cached via 25+ native SDKs, you can change behavior globally in under 200ms—after code is deployed.

Here’s how that looks in practice:

1. Before the release: wrap the feature in a flag.

   • Add a feature flag (for example, new_checkout_flow) in LaunchDarkly.
   • Guard all risky paths (new UI, new logic, new service integration) behind that flag.
   • Choose a safe default: false (old behavior) if you’re cautious, or true if you’re rolling forward but want a kill switch.

2. During the release: progressively expose it.

   • Use targeting rules in LaunchDarkly to start with internal users or a small percentage of traffic.
   • Increase exposure over time (1% → 10% → 50% → 100%) as you monitor real-time metrics.
   • If error rates spike, performance drops, or customer support lights up, you immediately know which flag is involved.

3. After a bad release: hit the kill switch—no redeploy.

   • Open the flag in LaunchDarkly’s UI (or via CLI, API, IDE, or MCP).
   • Toggle it off, or update the rule to exclude affected segments.
   • In under 200ms worldwide, the bad feature is disabled; users fall back to the safe path without a rollback deploy.

That’s the runtime control model: deploy once, then control behavior at the edge, at speed, using flags as operational levers instead of emergency redeploys.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Kill switches	Let you instantly turn a feature off in production via a flag toggle.	Recover from bad releases in seconds, without a rollback deploy.
Targeting & rollouts	Target flags to specific users, segments, or traffic percentages.	Limit blast radius and test risky changes in production safely.
Guarded releases	Monitor performance thresholds and trigger automatic pause/rollback.	Automate incident prevention and remediation—no manual 2am interventions.

Ideal Use Cases

• Best for critical, high-risk releases: Because you can ship complex changes (checkout flows, pricing, authentication, AI agents) with an instant kill switch and tight blast-radius control.
• Best for teams burned by rollback deploys: Because instead of coordinating hotfix branches, approvals, and redeploys, one person can flip a flag and restore stability instantly.

What “Instantly Disable a Feature” Looks Like Step-by-Step

Let’s map last week’s bad release to a safer future state.

1. Turn your risky feature into a controlled feature

Before your next release:

• Create a flag in LaunchDarkly:

  • Name: new_feature_x
  • Environments: production, staging, etc.

• In code, wrap the new behavior:

  // Example: Node.js
  const showNewFeature = await ldClient.variation("new_feature_x", user, false);
  
  if (showNewFeature) {
    // New behavior
  } else {
    // Old, stable behavior
  }
  

• Decide your default:

  • false if you want to dark launch and enable selectively.
  • true if you’re going all-in but still want a fast kill switch.

2. Separate deploy from release

With flags in place:

• Deploy the code as usual. The feature is technically in production but controlled by the flag.
• Release by toggling or targeting the flag from LaunchDarkly:
  • Initially: internal users only (by email domain, team, or segment).
  • Later: a small percent rollout to real users.

This decoupling is key: if something breaks, your recovery path is changing the flag, not the code.

3. When trouble hits, flip the flag instead of rolling back

In the scenario you described—bad release in production, error rates rising:

• Go to the flag in LaunchDarkly:
  • Option A: Set the flag to Off for everyone.
  • Option B: Change targeting rules (for example, “0% of users see new feature”).
• Save. The SDKs receive the update and evaluate accordingly:
  • With <200ms flag updates worldwide, users stop seeing the broken behavior almost immediately.
  • No new deploy, no code changes, no waiting for CI/CD.

You’ve effectively rolled back the feature, not the deployment.

Limitations & Considerations

• You must add flags before you need them:
  Kill switches only work if the feature is already wrapped. Make it a standard practice: any risky change goes behind a flag as part of the story definition and code review checklist.

• Flags require lifecycle management:
  Once the feature is stable and fully rolled out, that flag can become technical debt if you leave it forever. Use LaunchDarkly’s flag usage tracking, TTLs, and cleanup workflows to retire flags when they’re no longer needed.

Pricing & Plans

LaunchDarkly is sold as a runtime control platform with plans that scale as your flags, projects, and teams grow. Pricing typically reflects:

• Number of seats (developers, PMs, SREs, etc.).
• Environments and projects.
• Feature sets (Experimentation, Guarded Releases, AI Configs, Observability).

For specifics, talk to our team, but as a directional guide:

• Team / Growth Plans: Best for engineering teams that need reliable feature flags, kill switches, and progressive delivery in a handful of apps and services, plus core governance (environments, basic roles, audit logs).
• Enterprise Plans: Best for organizations with many teams and services needing advanced controls—custom roles, granular policies, release pipelines, experimentation, AI Configs, observability SDKs, and compliance-grade auditability.

Frequently Asked Questions

Do I need to redeploy every time I toggle a feature flag?

Short Answer: No. Once your code is integrated with LaunchDarkly’s SDKs, toggling a flag does not require a redeploy.

Details:
The SDK connects to LaunchDarkly and keeps flag configurations up to date in memory. When you toggle a flag in the UI, via API, CLI, or MCP, the change is pushed to SDKs in under 200ms worldwide. Your application simply evaluates the flag on each request or event and adjusts behavior based on the current value. That’s how you can disable a broken feature in production instantly—no CI job, no new container image, no rollbacks.

What if the bug is outside the flagged code path?

Short Answer: The kill switch only controls what you wrap in the flag, so you should flag the full risky surface area.

Details:
If a bug lives in code that is always executed—regardless of flag status—turning the flag off won’t help. To avoid this, design your flags around the actual failure modes:

• Wrap the entire new flow, not just a button or a single UI component.
• For backend changes, gate API handlers, new services, or integrations.
• For AI behavior, use AI Configs to control prompts, models, and agents, and wire those through flags so you can instantly revert to a prior config.

The more carefully you design flag boundaries, the more powerful your instant-disable lever becomes.

Summary

If last week’s bad release forced you into a painful rollback, that’s a signal that your team needs a better runtime control surface. Feature flags in LaunchDarkly let you:

• Deploy code when it’s ready, but decide who sees it at runtime.
• Limit blast radius through targeted, progressive rollouts.
• Instantly disable problematic features with a kill switch—no redeploys, no waking the whole team.

With 99.99% uptime, 45T+ daily flag evaluations, and <200ms flag updates worldwide, LaunchDarkly is built to make software releases boring again—even when you’re shipping fast.

Next Step

Get Started