Product Updates

Release Policies now support additional configuration options that make it easier to standardize how teams run guarded and progressive releases.

What’s new:

• Default traffic progression: Set the number, percentage, and duration of rollout stages
• Default Target-by context: Choose the context kind used for randomization
• Default metric selection: Preselect metrics teams should monitor during releases
• Tag scoping: Apply a policy only to flags with specific tags within an environment

Why it matters
Setting up a guarded or progressive release can be difficult if teams aren’t sure which metrics, contexts, or rollout stages to choose. Release Policies allow admins and engineering leads to define smart defaults so that individual contributors can ship safely without having to configure every detail. This helps teams adopt best practices and ensures consistent, reliable release workflows.

Learn more
Docs

Observability now supports multi-level ingestion filtering for sessions, errors, logs, and traces. You can define multiple ordered filter rules with precise conditions and sampling rates to control which telemetry is sent to LaunchDarkly.

Not all telemetry is equally important. Multi-level filters let you stack and reorder rules. For example, always include critical errors from a key service, exclude debug logs, or sample a small percentage of traces in staging, giving you finer control over noise, cost, and signal quality.

How it works
Go to Observability → Settings → Filters, choose a signal type, and add multiple rules with attribute queries and rates. Rules are evaluated top-down, and the first matching enabled rule applies. Anything that matches no rule is included by default.

Learn more
Docs

You can now use stratified sampling in LaunchDarkly Experimentation to reduce covariate imbalance and improve the reliability of experiment results. Instead of relying solely on random assignment, LaunchDarkly evaluates many candidate randomizations and selects the one that produces the most balanced control and treatment groups based on customer-provided attributes.

This helps teams avoid misleading results when a small number of high-impact users—such as large accounts—skew outcomes, and provides a stronger statistical foundation before an experiment begins.

Learn more
Docs

You can now collect qualitative user feedback directly from inside your LaunchDarkly feature flags. The new Feedback tab on any flag lets teams gather lightweight, contextual input from users during rollouts, right where you already monitor release health.

What’s new

• A guided setup flow that provides all the backend and frontend snippets needed to embed a feedback widget in your application
• Automatic attachment of flag metadata, including which variation each user saw
• Real-time feedback inside LaunchDarkly enriched with sentiment signals
• Seamless debugging workflows for Observability customers, including direct links from feedback to Session Replay

This brings user sentiment into the same workflow where you plan, monitor, and validate releases, helping teams quickly understand how changes landed and make fast, informed decisions.

Learn more
Tutorial

Lifecycle Settings gives you more control over how LaunchDarkly identifies stale flags. You can now customize the “ready to archive” and “ready for code removal” calculations on a per-project basis, allowing your team to define flag cleanup rules that match your organization’s own standards.

This update also includes a redesigned archive workflow that provides clearer visibility into a flag’s lifecycle state and whether it’s safe to archive, helping teams clean up with confidence.

Why it matters
Stale flag cleanup is critical for long-term flag management, but every organization defines “stale” differently. Lifecycle Settings lets teams tailor LaunchDarkly’s status calculations to their own workflows so they can more easily organize, filter, and operationalize flag cleanup.

Learn more
Docs
Video overview