Feature Management Platforms
How do we set up Guarded Rollouts in LaunchDarkly Guardian to auto-pause or roll back when guardrail metrics fail?
7 min read
Shipping fast is only useful if you can hit pause just as fast when something breaks. Guarded Rollouts in LaunchDarkly Guardian give you that safety net: you define the guardrails, and Guardian will automatically pause or roll back your rollout in production when those metrics fail—no redeploys required.
Quick Answer: Guarded Rollouts use Guardian’s automated monitoring to watch your feature flag rollouts in real time. You attach guardrail metrics (like error rate or latency), define thresholds and actions, and Guardian will automatically pause or roll back exposure the moment those guardrails are breached.
The Quick Overview
- What It Is: A runtime safety layer for feature flag rollouts that automatically pauses or rolls back when guardrail metrics (errors, latency, etc.) regress.
- Who It Is For: Engineering, SRE, and product teams that want to ship continuously, reduce blast radius, and avoid 2am fire drills.
- Core Problem Solved: Releases that silently degrade performance or reliability, forcing slow, manual decisions to revert via redeploys.
How It Works
At a high level, Guarded Rollouts sit on top of your existing feature flags. Instead of treating a rollout as “flip to 10%, wait, flip to 50%…”, you define a policy that tells Guardian:
- Which flag and environment to monitor
- Which metrics are “guardrails” (e.g., error rate, latency, failed logins)
- What thresholds are acceptable during the rollout
- What to do when those thresholds are crossed (auto-pause, auto-rollback)
Guardian then continuously evaluates live traffic in production. As exposure to the flagged experience increases, Guardian compares current metrics to your thresholds. If a guardrail fails, Guardian takes the action you’ve defined—automatically, in under 200ms worldwide—without you touching the codebase.
Think of it as: Release / Observe / Auto-React.
1. Define the rollout and targeting
You start by configuring a progressive rollout on a LaunchDarkly feature flag:
- Choose the flag and environment (e.g.,
checkout_v2inproduction). - Set up your targeting rules: segment, attributes (plan type, OS, region), or a percentage rollout.
- Set the rollout schedule: e.g., 5% → 25% → 50% → 100%, either manual steps or automated over time.
Guarded Rollouts build on these standard progressive delivery controls. You’re essentially saying: “Roll this out to more users, but only if the system stays healthy.”
2. Attach guardrail metrics and thresholds
Next, you configure what “healthy” means by attaching metrics to the rollout:
- Connect metrics via:
- LaunchDarkly SDK events
- OpenTelemetry
- Error monitoring tools like Sentry
- Other observability integrations
- Pick the metrics you care about:
- HTTP error rate (e.g., 5xx)
- Latency (p95/p99 response time)
- Front-end performance (LCP/INP/CLS)
- Business health signals (e.g., checkout success rate)
- Define performance thresholds:
- “Error rate must stay below 1%”
- “p95 latency must not increase by more than 20%”
- “Conversion rate must not drop by more than 3%”
- Choose monitoring windows:
- Template windows from minutes to days depending on traffic and risk.
- Short windows for fast-moving incidents; longer for subtle regressions.
Guardian continuously evaluates these metrics as the rollout progresses, using your monitoring windows to avoid reacting to random noise while still catching real regressions in real time.
3. Configure actions: auto-pause and auto-rollback
Finally, you tell Guardian how aggressively to react when guardrails fail:
- Auto-Pause:
- Freeze the rollout at the current exposure.
- Stop progressing to more users.
- Keep serving the new experience to the current cohort for investigation.
- Auto-Rollback:
- Immediately revert the flag to a safer state (e.g., 0% or previous version).
- Act as a kill switch tied to metrics instead of a human decision.
You can optionally:
- Trigger alerts (PagerDuty, Slack) via Regression Detection so humans are pulled in with context.
- Log all actions in audit logs and release pipelines for governance and compliance.
- Use policies and approvals so only the right people can modify guardrail settings.
Once configured, Guardian watches every evaluation for that flag. When the metric trend crosses your threshold, Guardian executes the defined action globally in under 200ms, backed by LaunchDarkly’s 99.99% uptime and 45T+ daily flag evaluations.
Features & Benefits Breakdown
| Core Feature | What It Does | Primary Benefit |
|---|---|---|
| Guarded Rollouts Policies | Attach guardrail metrics and thresholds to progressive rollouts. | Reduce blast radius by tying rollout speed to real health signals. |
| Automated Pause & Rollback | Automatically freeze or revert rollouts when metrics fail. | Recover instantly from bad releases without redeploying or paging on-call. |
| Runtime Observability Integration | Monitors errors, latency, and other metrics in real time during rollouts. | See what broke and why, directly tied to specific flags and versions. |
Ideal Use Cases
- Best for risky releases with high blast radius: Because Guarded Rollouts can lock exposure or roll back automatically when performance thresholds are breached, keeping incidents contained to a small portion of traffic.
- Best for continuous delivery teams shipping many times per day: Because Guardian monitors every rollout in real time, teams can move faster without manually babysitting dashboards.
Limitations & Considerations
- Metric quality and coverage matter: Guardian can only react to what it sees. Make sure critical paths emit reliable metrics via SDKs, OpenTelemetry, or your error/perf tools. If a flow isn’t instrumented, consider adding basic counters before trusting auto-rollback.
- Threshold tuning takes iteration: Overly tight thresholds may cause noisy pauses; overly loose thresholds might miss real regressions. Start with conservative values, run a few rollouts, and adjust based on observed behavior.
Pricing & Plans
Guardian and Guarded Rollouts are part of LaunchDarkly’s runtime control platform. Exact pricing depends on your edition, usage, and the scale of flags/environments you run in production.
Typical patterns:
- Growth / Team Plan: Best for product and engineering teams needing progressive delivery with basic guardrails and standard environments.
- Enterprise Plan: Best for large organizations needing advanced policies, approvals, detailed audit logs, custom roles, and scaled Guarded Rollouts across many services and teams.
For precise details, talk to LaunchDarkly directly or request a demo.
Frequently Asked Questions
Do Guarded Rollouts work with existing flags, or do we need new ones?
Short Answer: They work with your existing feature flags; you don’t need to redesign your flag strategy.
Details:
Guardian is designed to layer on top of the feature flags you already use for progressive delivery. You select an existing flag and environment, then define a Guarded Rollout policy that covers that rollout. You’ll typically:
- Keep your current targeting and percentage rollout rules.
- Attach guardrail metrics and thresholds to that specific rollout.
- Decide whether Guardian should auto-pause, auto-rollback, or both when guardrails fail.
This lets you turn a standard flag rollout into a guarded one without changing your code or redeploying.
How is this different from just watching dashboards and manually rolling back?
Short Answer: Guardian reacts in milliseconds based on predefined rules; humans react in minutes based on dashboards and hunches.
Details:
Manual monitoring relies on someone:
- Watching metrics at the right time.
- Recognizing that a change is tied to a specific rollout.
- Making a judgment call and then triggering a rollback or updating flag rules.
Guarded Rollouts automate this loop:
- Metrics are pre-wired to specific flags and versions.
- Thresholds are pre-agreed (e.g., “don’t accept >1% error rate”).
- Actions are pre-defined (pause vs rollback).
When a guardrail fails, Guardian acts immediately—often before humans would even notice the spike. You still keep humans in the loop via alerts and audit logs, but the first line of defense is automated and consistent.
Summary
Guarded Rollouts in LaunchDarkly Guardian turn your feature flags into self-defending release controls. You configure the rollout, bind it to the metrics that matter, and define what “too risky” looks like. From there, Guardian monitors in real time, automatically pausing or rolling back when guardrails fail—so you can ship more often, with less blast radius, and without relying on late-night redeploys.