Product Updates

Flag Delivery v2 (FDv2) is now available in Early Access for the LaunchDarkly .NET Server-side SDK v8.11.0, bringing faster initialization, smarter data handling, and improved resiliency to feature flag delivery.

FDv2 introduces several key enhancements:

• Two-phase initialization: Start quickly from a polling data source, then synchronize from a long-lived streaming connection.
• Data-saving mode: Resume from a previously saved state during reconnects to reduce bandwidth and processing time.
• File-based initialization: Initialize from a local file first, then connect to LaunchDarkly APIs for updates.
• Automatic failover: Seamlessly switch to polling if the streaming connection fails.
• Improved flag caching: When using a persistent store in non-daemon mode, flag data is no longer limited by cache TTL.

Together, these improvements make flag delivery faster, more reliable, and more efficient across all environments.

Availability
Early Access: Data-saving mode is only available to members of LaunchDarkly’s Early Access Program (EAP). If you want access to this feature, join the EAP.

Learn more
Data-saving mode documentation

Sequential testing is now available for Frequentist experiments in LaunchDarkly Experimentation. You can monitor results during the run and stop early when outcomes are clear while maintaining valid statistical guarantees under repeated looks.

What’s new

• Enable sequential testing when creating a Frequentist experiment
• Check results throughout the experiment without invalidating inference
• Stop early when a winner emerges or results are unlikely to change meaningfully

Why it matters
Fixed-horizon tests require choosing a sample size up front and discourage interim reads. Sequential testing supports real-world workflows by allowing teams to make decisions sooner, educing time-to-insight and unnecessary user exposure, without sacrificing rigor.

Learn more
Docs

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