LaunchDarkly Release Notes

Add a safety check before experiment changes reach users.

Feature flag changes are not the only production changes that need governance. Experiments do, too. Every experiment has the potential to change a user’s experience, shift traffic, affect business metrics, or influence a product decision. For teams operating in regulated environments—or any organization with strict change management practices—that makes review and accountability essential. That’s why we’re introducing Experiment Approvals, now available in beta. Experiment Approvals extends LaunchDarkly approval workflows to experimentation, giving teams a governed way to start, modify, stop, and ship experiments with the right review in place. The result: more control over experimentation without slowing down the teams responsible for learning fast.

More end-to-end control

Experimentation is one of the most powerful tools a product team can wield. It turns gut feelings into evidence and feature launches into learning opportunities. And for teams already using LaunchDarkly approval workflows for flag changes, it's always made sense to extend that same level of oversight to experiments—the moments when traffic allocation, variant configurations, and key metrics are on the line. With Experiment Approvals, organizations now have a safeguard to help ensure best practices are upheld. For teams operating under compliance requirements, internal change management policies, or strict audit obligations, this means LaunchDarkly can cover the full picture. Not just flags, but every experiment that touches production. For regulated industries, this is especially meaningful. Dual-control requirements, self-approval restrictions, and audit trail mandates apply to production changes of all kinds. Experiment Approvals helps ensure LaunchDarkly meets those requirements end-to-end.

What Experiment Approvals does

Experiment Approvals works just like flag approvals, applied to your entire experimentation workflow. If you already have flag approvals enabled, you're nearly set up. For everyone else, an Admin can turn it on at the environment level.

Here's what it covers:

• Starting an experiment requires approval before traffic is allocated to variants. Experiment creators submit the experiment for review, select approvers, add context, and wait for sign-off before anything goes live.
• Stopping an experiment or shipping a variation follows the same pattern. Whether you're ending a test early or rolling out a winning variant, that action can require explicit approval, giving your team visibility into every significant change before it affects users.
• Modifying a running experiment—changes that would initiate a new iteration—also can require approval. Approvers see a clear diff of what's changing, including both the experiment configuration and the associated flag-targeting rules, so decisions are made with key context.
• A centralized approvals interface gives reviewers a single place to see pending requests, review change details, and approve or decline. Notifications land in the LaunchDarkly inbox via email and Slack. Additional integrations are planned.
• Audit log integration captures every approval request, decision, and application, including who requested it and who approved it. Self-approval prevention is configurable for organizations that require it.

Built for the agentic future

LaunchDarkly has been investing in making our platform accessible to AI agents, and experimentation will be a key part of that journey. That future is exciting, but it introduces a new set of governance challenges.

Experiment Approvals is the foundation that makes agentic experimentation safer. When an agent proposes a large traffic ramp, launches an experiment on a sensitive surface, or makes a change that crosses a risk threshold, the approval workflow is designed so that a human stays in the loop. Low-risk, routine actions can move quickly. Higher-stakes changes route through review.

We're building toward a policy-based model where organizations can define which agent actions require human approval and which can proceed automatically. Experiment Approvals is step one.

Learn more about approvals here.

Get access to Experiment Approvals

Experiment Approvals is available in beta to all customers with LaunchDarkly Experimentation. If you’re interested in getting access to try it out, please contact us.

Original source

Adaptive Triggers is now available in closed beta.

The gap between something going wrong with a production AI system and getting the right fix live has never been zero. An alert fires, someone diagnoses the cause, a decision gets made, the fallback goes live—and users are experiencing the problem throughout. For traditional software, that gap is at least bounded: Behavior stays stable between deploys, and the sources of change are largely things you shipped.

Agents don't work that way, as agents and models are inherently unpredictable and indeterminate. Model checkpoints update on the provider's schedule, provider health fluctuates, and environment changes that nobody on the team initiated can shift behavior that was working reliably the day before. The gap between detection and response is the same as it always was, but the surface area for something going wrong is much larger, and most of it is outside your control.

Most teams running agents in production have already defined what to do when something goes wrong: a fallback model with a backup provider, a more conservative configuration for when the primary fails. The alternative is there, already wired up. What's been missing is the mechanism that activates it at the moment the signal arrives, without waiting for someone to make the call. Today, we’re happy to introduce the missing piece.

Adaptive Triggers is now available in closed beta. Teams define a rule directly on a config: When a monitored metric breaches a threshold within a time window, switch to a specified variation. When the threshold is crossed, AgentControl makes the switch automatically, with no human in the loop.

A team running their agent on Claude Sonnet hosted on AWS Bedrock has a backup variation configured to route the same model to GCP Vertex. When Bedrock error rates climb past the configured threshold (say, more than 10 failures in five minutes), the trigger fires. AgentControl switches the default variation to the Vertex configuration and traffic reroutes. The experience is uninterrupted, and nobody gets paged.

The response that doesn't wait

What makes the switch instant isn't only that it's automated. Because AgentControl controls the configuration layer, the fallback variation has already been pulled by the SDK and is instrumented in the running system. When the trigger fires, there's nothing to build and no deployment to kick off. The switch happens in under 200 milliseconds because AgentControl sits inside the application, not between it and the model provider. The team made the decision about what to do in advance, and Adaptive Triggers executes it the moment the signal arrives.

Most tools can surface a problem or change a setting. Adaptive Triggers does both automatically, in real time, inside the same platform. The gap between seeing a production problem and responding to it closes when the response is already defined.

The direction from here extends to every signal in the observe-and-act loop: quality scores that drop below threshold, cost spikes that warrant routing to a lighter configuration, paired triggers that restore the primary variation automatically when metrics recover. The response that doesn't wait becomes a loop that runs on its own.

Adaptive Triggers is available in closed beta. Reach out to your account manager to request access.

Original source

Agent Optimization is now available in private beta for eligible customers.

Developers improve agents through iteration: Change something, run a test, see if it feels better, repeat. The process has a ceiling, though, and you can only test configurations you thought to try, with the starting point for each change shaped by what you've already built. The best configuration you find through manual iteration is the best one you imagined, not necessarily the best one that exists. What if there were a way to improve agents automatically?

Agent Optimization is now available in beta in AgentControl for eligible customers. You start by defining acceptance criteria for your agent: what a good response looks like, how it should be structured, what it should and shouldn't do. From there, Agent Optimization generates combinations of models, prompts, and hyperparameters to test, evaluates each iteration against those criteria using a judge model, and surfaces the one that performed best. The exploration isn't bounded by configurations anyone thought to try.

A team building a customer support triage agent defines their acceptance criteria: accurate classification of support queries, and responses that begin immediately with the category rather than preamble. They trigger an optimization run and, three iterations later, the winning configuration scores 0.95 on both acceptance criteria while latency has dropped from 8 seconds to 3.4 seconds and cost per run has fallen alongside it. The system found a configuration that's equally accurate, substantially faster, and cheaper. Manual iteration might have eventually reached the same result, or might have traded off quality trying to get there.

Exploring the configuration space

Two optimization modes shape how the exploration runs. Exploratory mode is for agents with open-ended or unpredictable input spaces, which is useful when the goal is mapping behavior across a wide range of inputs rather than validating against known outputs. Expected Output mode is for agents where input/output pairs already define correct behavior, and the goal is to improve performance without regressing on what already works.

From optimization to production

When a run surfaces a winning configuration, it can be promoted directly from the results view to a config. The configuration that passed optimization ships as a variation, and from that point, the rest of the AgentControl system applies: guarded rollout to ramp traffic progressively, online quality scoring through AI Insights to track how it performs in production, and the same controls that govern any other configuration change.

This is where the offline optimization run connects to the production system. The configuration that performed best in a controlled environment now gets tested against real traffic, with the results feeding back into the picture of how agents are actually behaving. That path, from controlled evaluation to production measurement, is what AgentControl is building toward. Today, teams trigger the run and review the results. What the platform is working toward is agents that surface their own improvement opportunities from what's happening in production and apply them, without waiting on a manual iteration cycle.

Getting started with Agent Optimization

Agent Optimization is available in private beta. Reach out to your account manager to learn more and request access.

Original source

Today is an important day for LaunchDarkly and our customers: We’re launching AgentControl, a new solution that helps teams control not just code in production, as we have for over a decade, but also the AI agents acting on their behalf.

AgentControl gives teams one place to configure, evaluate, observe, and control agents in production, without building or stitching together separate tools.

This is more than a new product for us. It reflects a broader shift in how software is built, released, and improved in this era of AI, and how LaunchDarkly is evolving to support you into the future.

Why we started LaunchDarkly

I cofounded LaunchDarkly in 2014 to solve a problem I’d experienced firsthand. As an engineering manager and product manager, I’d felt the pain of bad releases, software that missed the mark, and customers left angry or disappointed.

We built LaunchDarkly to help teams separate deployment from release so they could roll out changes safely, measure impact, and iterate quickly. It was the tool I wanted, not just to de-risk releases, but to ensure the right functionality reached the right users at the right time.

Over the past decade, we’ve helped thousands of customers move from infrequent, high-risk, all-or-nothing releases to continuous delivery. Today, software teams can ship in minutes, learn in real time, and improve continuously with confidence and control.

That core idea of reducing risk and speeding up the cycle from idea to production hasn’t changed. But AI has fundamentally changed and accelerated software development.

AI has introduced new challenges

Everything is moving faster—faster than teams can manually review, validate, and control.

In 2024, LaunchDarkly introduced guarded releases to help teams deal with the increase of AI-built code. By tying releases to critical metrics, guarded releases gave teams automated runtime control for code, with the system detecting issues in production and automatically taking action before customers were impacted or teams needed to intervene.

That was the first wave of change, but now we’re entering the second. Agents are being put to work in production at scale—from customer-facing experiences to back-end operations—making decisions, taking action, and evolving over time.

Agents don’t fail like traditional software. They drift. Models update, context shifts, and behavior changes without a single line of code changing. Pre-production controls can’t stop this, and the standard playbook—detect, fix, redeploy—breaks down for AI systems that never stop evolving.

When agents behave, they’re incredibly powerful. When they misbehave, they create unacceptable risk. You can’t catch this before production. You have to control it in production.

What we're launching

AgentControl is our control plane for AI systems in production.

With AgentControl, teams can define prompts, models, tools, and parameters as runtime-changeable AI configs—versioned and updated without redeploys. Teams can experiment and validate changes offline against their own datasets, then continuously evaluate live traffic in production for latency, cost, quality, and behavioral drift.

Those real-time signals can then trigger automated action through guarded releases: rerouting traffic, rolling back changes, adjusting configurations, or shutting down problematic behavior before customers are impacted.

Most AI tooling helps you observe and evaluate. AgentControl helps you ship and control, closing the loop from signal to action without waiting through a deploy cycle. And all of this runs on the same battle-hardened delivery infrastructure that powers 50 trillion evaluations a day for thousands of the world's largest and most innovative companies.

AgentControl is already helping teams govern and scale agents, optimize AI spend and performance, and continuously experiment and improve in production, including our own teams here at LaunchDarkly.

We believe this is the foundation for a new generation of software systems that can safely heal themselves and continuously optimize toward better outcomes.

Runtime control for code and agents

Runtime control for both code and agents helps teams move faster and safer, and fully realize the value from AI.

In this new era, the best teams will stay in control, setting goals and guardrails while using agents that ship continuously, learn instantly, and adapt in real time. That’s the future we’re building toward.

We’re incredibly grateful to be building alongside you, and can’t wait to see what you create.

Please join us at our launch event on June 11 at 10 a.m. PT to learn more about AgentControl and check out our updated website —we’ve put a little more color into LaunchDarkly!

Original source

AgentControl is the operational layer for managing agents in production.

Most engineering teams spent the last year figuring out what agents could do. Developers built a lot across different frameworks and approaches, and enough of it made it to production that a harder problem has taken its place: Building agents is no longer the challenge—operating them at scale is.

Unlike traditional software, where behavior is expected to remain stable after deployment, agents have no equivalent moment of “done” as agents and models are inherently unpredictable and indeterminate. With agents, behavior can degrade without a code change as model checkpoints update, environments shift, and something that worked reliably can drift without anyone on the team touching it. When something goes wrong, customers can feel it before anyone on the team does, and the standard response (find it, fix it, redeploy) is often too slow for a system that never stops running. The problem compounds when organizations are running multiple agents across different frameworks and codebases, with no shared standard for how any of it is governed.

Most teams running agents in production have invested in observability and generally know when something is wrong, but visibility into a problem and the ability to act on it fast enough to matter are different things. Layering monitoring on top of whatever framework the team started with (or assembling point solutions around it) still leaves the same gap: An alert tells you something degraded, but it doesn't act on it, and the controls needed to respond aren't in the same place as the data that surfaced the problem, which leaves teams well-informed about an issue but scrambling to fix it.

"More and more, developers are not just writing code. They are directing agents, which is fundamentally changing how work flows. GitHub is where that work actually happens: where people and agents build, review, and ship software together in a single system. The challenge is turning agent-generated work into code that can be validated, governed, and safely shipped to production. LaunchDarkly has been solving release governance for years, and AgentControl extends that to agentic workloads. Together, we give teams a real path to ship agents and agent-built software without losing governance, observability, or control. That’s what it looks like to scale responsibly."

— Mario Rodriguez, GitHub Chief Product Officer

AgentControl is the operational layer for managing agents in production. It runs on the LaunchDarkly flag delivery infrastructure, the same network handling 50T+ flag evaluations a day, which turns out to be well-suited to the problem: The things that shape agent behavior (prompts, models, parameters, tools) need to be updatable faster than a deployment cycle allows. Models and prompts can be changed in under 200 milliseconds, targeted to specific users, and governed from a single place across every team in the organization. LLM traces surface what's happening across agent invocations, and the platform connects that observability to the controls needed to act on it, so teams can catch quality, cost, and reliability problems before customers do.

"To deliver best-in-class AI agents to our customers, we need to keep pace with the latest frontier models. AgentControl lets us systematically test and upgrade our agents in production without waiting on a full deployment cycle."

— Zack Rossman, Senior Staff Engineer, Veeam

AgentControl covers the full agent lifecycle, including:

• Offline Evals: Benchmark prompt and model variants against curated test datasets before anything ships, with LLM judges scoring each candidate against the quality criteria the team defines.
• Guarded Rollouts: New agent versions can be rolled out progressively, with automatic rollback triggered by quality, cost, or latency signals, so regressions can be contained before they reach the full user base.
• Online Evals: LLM judges score agent outputs continuously in production against team-defined quality metrics, so teams have a real-time signal on how the system is performing against what matters.
• AI Insights: Tracks how changes to prompts, models, and parameters move key metrics (cost, quality, latency, business outcomes) over time, so teams can correlate configuration decisions to actual outcomes rather than inferring causation from incomplete signals.
• Experimentation: Run A/B and multi-armed bandit experiments on live traffic, scored by LLM judges and business metrics, so the decision about which configuration to ship is based on what actually performs better.
• Agent Optimization (private beta): Teams define the goal and the metrics that matter, and AgentControl creates the variants, runs the evals, and surfaces what performed best on their behalf.
• Adaptive Triggers (private beta): What the other capabilities observe and measure, Adaptive Triggers acts on. Define the conditions and the response in advance: If error rates from a provider breach a threshold, switch to another; if quality scores drop, escalate to a more capable agent. The team decides what to do and AgentControl handles it automatically, before a bad response reaches the user.

“Most of the clients we work with are done proving AI works and need it to actually perform at scale, with real ROI, and enterprise-grade reliability. That's when the operational reality hits: behavior drifting in ways nobody anticipated, definitions scattered across teams and repos, and no reliable way to intervene before a customer feels the impact. This governance problem is one of the first things we tackle when we come in, and AgentControl is the first platform we've found that closes that gap—the ability to change how an agent behaves before a bad response reaches a customer, without touching code, is something our clients now treat as a foundational requirement."

— Clay Campbell, CEO, Seawolf AI

What ships today is the difference between knowing something went wrong and having already handled it. What the platform is building toward is a tighter loop: Production data feeding back into configuration continuously, and the system improving without waiting to be told what to fix.

AgentControl is available now.

Original source

Overview

This topic explains how data saving mode works in the LaunchDarkly SDKs that support it, listed below. The Relay Proxy also supports data saving mode.

Server-side SDKs in data saving mode first open a polling connection to LaunchDarkly. The initial payload from this connection contains the data the SDK will need to operate and perform flag evaluations.

Subsequently, server-side SDKs in data saving mode open a streaming connection and receive realtime flag configuration changes over the stream. These configuration changes include only the difference between the server-side SDK’s stored configuration and the latest configuration in LaunchDarkly. The SDKs use in-memory data for the unchanged aspects of the flag configuration.

The SDKs fall back to using a polling connection if LaunchDarkly streaming is unavailable. Data saving mode includes additional configuration options that let you set a backup data source, enabling automatic failover if a connection is unavailable.

Depending on the number of flags in your project and the complexity of their configuration, data saving mode can significantly improve performance, including reducing your network costs when in polling mode or on reconnection. Additionally, SDKs in data saving mode have reduced memory and CPU usage overall.

Track service connection usage by application

When using data saving mode, you can track which applications are consuming service connections by configuring application metadata. Set the applicationId in your SDK configuration to see a per-application breakdown on the Service connections usage page under the SDK App ID dimension. Server-side streaming connections without applicationId configured appear as “Unknown.” To learn how, read Application metadata configuration.

Server-side SDKs

This feature is available in the following SDKs:

• .NET (server-side)
• Go
• Java
• Node.js (server-side)
• Python
• Ruby

.NET (server-side)

[Code sample expandable section]

Go

[Code sample expandable section]

Java

[Code sample expandable section]

Node.js (server-side)

[Code sample expandable section]

Python

[Code sample expandable section]

Ruby

[Code sample expandable section]

Original source

Contact us for help with configuring Redshift native Experimentation

If you have both Data Export and Experimentation enabled for your LaunchDarkly account, you should have access to Redshift native Experimentation. If you do not have access or need help getting started, contact your LaunchDarkly representative or start a Support ticket.

Overview

This topic explains how to set up the Redshift warehouse native Experimentation integration. Redshift native Experimentation enables you to run experiments in LaunchDarkly using data directly from your Amazon Redshift data warehouse. This lets LaunchDarkly experiments read and analyze your metrics data stored in Redshift, without requiring you to send event data through LaunchDarkly’s SDKs.

Before you can begin running Redshift native experiments, you must configure the Redshift Data Export integration in LaunchDarkly.

Prerequisites

Before setting up Redshift native Experimentation, ensure that you have:

• The Redshift Data Export integration set up in LaunchDarkly.
• Administrative access to your AWS account with permissions to create IAM policies and roles
• An active Amazon Redshift cluster
• A LaunchDarkly role of Owner or Admin, or a custom role that allows the following actions:
  • add and edit integrations
  • add destinations
  • add metric data sources
• Metric event data in your Redshift database that you want to use for Experimentation

Step 1: Gather your Redshift cluster information

To begin, collect the following information about your Redshift cluster:

• The full cluster endpoint URL, similar to my-cluster.abc123.us-east-1.redshift.amazonaws.com
• Your cluster’s unique identifier, similar to my-redshift-cluster
• The region where your AWS cluster is deployed, such as us-east-1
• Your 12-digit AWS account ID
• The name of the database containing your metrics data
• The name of the schema within the database where metrics tables are located

You can collect this information from your cluster’s “General information” screen.

Step 2: Configure the LaunchDarkly integration

This step collects your connection details you gathered in the previous section and generates the IAM policy you’ll use in the next step. This integration is a second LaunchDarkly integration that looks similar to the Redshift Data Export integration, but requires a separate setup process.

To set up the integration:

1. Navigate to the Integrations page.
2. Search for and select Redshift Native Experimentation.
3. Click Add integration. The configuration panel appears.
4. Enter an integration Name.
5. Select the LaunchDarkly Project and environment for this integration. You cannot change this after you save the integration.
6. Enter your Redshift endpoint cluster URL.
7. Enter your Redshift cluster identifier.
8. Enter the Redshift cluster region where your cluster is deployed.
9. Enter your 12-digit Redshift cluster AWS account ID.
10. LaunchDarkly automatically populates the following fields. Copy and save the JSON and SQL from these fields for use in the next section:
    • IAM policy
    • Trust Policy JSON
    • SQL Setup Script
11. Enter the Metrics database name containing your metrics data.
12. (Optional) Enter the Metrics schema name containing your metrics tables.
13. LaunchDarkly automatically populates the SQL setup script field. Copy and save the SQL for use in the next section.
14. Click Create.

Next, you will create AWS Resources using the JSON and SQL you copied and saved in this section. Leave the LaunchDarkly integration page open, as you will return to it at the end of the next section.

Step 3: Create AWS resources

Use the JSON and SQL scripts you saved in the previous section to create the required resources in your AWS account.

Create the IAM policy

1. In the AWS console, navigate to IAM > Policies.
2. Click Create policy.
3. Select the JSON tab.
4. Paste the IAM Policy JSON you copied from LaunchDarkly.
5. Click Next.
6. Enter a policy name, such as LaunchDarklyRedshiftAccess.
7. Click Create policy.

Create the IAM role

To create the IAM Role:

1. In the AWS Console, navigate to IAM > Roles.
2. Click Create role.
3. Select Custom trust policy.
4. Paste in the trust policy JSON you copied from LaunchDarkly in step 2.
5. Click Next.
6. Search for and select the policy you created in the previous section, such as LaunchDarklyRedshiftAccess.
7. Click Next.
8. Provide a role name, such as LaunchDarklyRedshiftRole.
9. Click Create role.
10. Copy and save the Role ARN from the role summary page.
11. Return to the LaunchDarkly integration configuration page and paste the Role ARN into the AWS IAM Role ARN field.

Configure the Redshift database

Next, configure the Redshift database:

1. Follow AWS’s instructions to connect to your Redshift cluster using your preferred SQL client.
2. Paste and run the SQL setup script you copied from LaunchDarkly in Step 2. The SQL script includes several comments to assist with your Redshift configuration.

The script creates the required database user and grants the necessary permissions for LaunchDarkly to read your metrics data.

Step 4: Configure network access

Ensure your Redshift cluster can receive connections from LaunchDarkly’s infrastructure by whitelisting the following IP addresses:

1. Navigate to your Redshift cluster in the AWS console.
2. Go to Properties > Network and security.
3. Edit the VPC security group.
4. Add inbound rules for each of the following IPs. Set the Type to “Custom TCP” and the Port to “5439”:
   • 52.21.152.96/32
   • 52.200.35.24/32
   • 52.200.50.23/32
   • 54.144.218.89/32
   • 54.221.221.197/32
   • 34.236.6.43/32

Step 5: Verify the connection

Finally, verify the connection. On the integration configuration page, check the “Connection status” indicator. A green Healthy status confirms LaunchDarkly can connect to Redshift and has the correct permissions.

If you encounter issues with your setup, you can take the following actions:

• Check the integration status in LaunchDarkly for error messages
• Review your AWS CloudTrail logs for IAM role assumption attempts
• Check your Redshift system tables for connection and query logs

If you are still having trouble with your connection contact LaunchDarkly Support with the following information:

• Your integration configuration ID
• Any error messages from the connection status
• Your AWS CloudTrail logs, if available
• Your Redshift cluster configuration details, including endpoint, region, and version

Next steps

Read the following topics to understand how to create a Redshift native experiment and analyze the experiment results:

• Creating experiments using warehouse native metrics
• Analyzing experiments

The results page for a warehouse native experiment displays the date and time the results were last updated from Redshift. The initial load of experiment results can take up to 60 minutes to appear, and further results updates appear within 15–30 minutes.

Original source

The React Web SDK does not work in React Native projects

If you want to add LaunchDarkly to your React Native codebase, use the React Native SDK instead. The React Web SDK is intended for use in web applications, and the React Native SDK is specifically designed to run in mobile environments. To learn more, read React Native SDK.

Overview

This topic documents how to get started with the client-side React Web SDK, and links to reference information on all of the supported features.

SDK quick links

LaunchDarkly’s SDKs are open source. In addition to this reference guide, we provide source, API reference documentation, and a sample application:

• SDK API documentation: SDK API docs
• Supported SDK Versions: React Web SDK
• GitHub repository: js-core/packages/sdk/react
• Sample application: React Web
• Published module: npm

Similar documentation for React Server Component support is available in React Server Component support.

Get started

After you complete the Get started process, follow these instructions to start using the LaunchDarkly React Web SDK in your React code:

• Understand version compatibility
• Install the SDK
• Initialize the client
• Identify the context
• Subscribe to flag changes
• Access flag values

Understand version compatibility

The React Web SDK is based on the JavaScript SDK. The React Web SDK builds on LaunchDarkly’s JavaScript SDK to provide a better integration for use in React applications. As a result, much of the JavaScript SDK functionality is also available for the React Web SDK to use. For a complete client-side JavaScript SDK reference, read JavaScript SDK reference.

The React Web SDK version 4.0 requires React version 18.0.0 or higher.

The LaunchDarkly React Web SDK versions 3.0 and higher are compatible with React version 16.3.3 and higher.

The LaunchDarkly React Web SDK versions 2.x are compatible with React version 16.3.0 and higher.

The LaunchDarkly React Web SDK offers eight custom hooks. If you want to use these, then you must use React version 18.0.0 or higher. To learn more, read Hooks.

Install the SDK

Install the React Web SDK using npm or yarn.

We recommend making the LaunchDarkly observability plugins available as well. These plugins collect and send observability data to LaunchDarkly, including metrics autogenerated from observability events. This means you can review session replay, error monitoring, logs, and traces from within the LaunchDarkly UI. They require the React Web SDK version 3.7 or later.

Initialize the client

After you install the dependency, your code must initialize the React Web SDK before it can evaluate flags. To do this, we recommend using createLDReactProvider to create an SDK client provider and useInitializationStatus to determine the appropriate time to evaluate your flags.

createLDReactProvider relies on React’s Context API, which lets you access your flags from any level of your component hierarchy. The React Context API is unrelated to LaunchDarkly contexts.

To initialize the React Web SDK, you need your LaunchDarkly environment’s client-side ID and the context for which you want to evaluate flags. This authorizes your application to connect to a particular environment within LaunchDarkly.

React Web SDK credentials

The React Web SDK requires a client-side ID. Client-side IDs are specific to each project and environment. They are not secret, and you can include them in client-side code. Do not embed a server-side SDK key in a client-side application. You can find client-side IDs and project keys in Project settings, on the Environments list. To learn more about key types, read Keys.

If you connect the React Web SDK to the ldcli dev-server for local testing, use your project key instead of a client-side ID. Set all service endpoints to http://localhost:8765. If you use a client-side ID, the SDK connects to LaunchDarkly rather than the dev-server, which can result in CORS errors.

The createLDReactProvider function initializes the React Web SDK and returns a Context Provider, which is a React component.

You must initialize createLDReactProvider at the app entry point, prior to rendering, to ensure that flags and the LaunchDarkly client are ready at the start of your React app lifecycle.

This provider enables the use of the new useInitializationStatus status hook, which you can use to react to initialization status updates. Typically, you would want to wait for the SDK initialization status to be complete before trying to evaluate flags.

Example initialization code is provided for React Web SDK v4.0.

Alternative initialization processes:

• You can use createLDReactProviderWithClient to more easily manage multiple SDK client instances.
• You can use createClient to manage your own client instance without React context.

Identify the context

After initialization is complete, your flags and the client are available at the start of your React app lifecycle. This ensures your app does not flicker due to flag changes at startup time.

In the React Web SDK, all SDK clients must be initialized with an initial context. If you do not know which context to initialize the SDK with, then we recommend initializing the SDK with an anonymous context. You can use the identify function to change this context at any time.

Example code shows how to identify the context after initialization.

Subscribe to flag changes

The React Web SDK will subscribe to individual flag change events when you use one of the variation hooks or the variation details hooks. This will automatically open a streaming connection.

In some cases, streaming may not be necessary. For example, if you reload your entire application on each update, you will get all the flag values again when the client is re-initialized. In this situation, we recommend disabling streaming mode. To disable streaming mode, set streaming: false on the ldOptions you pass to createLDReactProvider. When streaming is disabled, no live updates occur.

In other cases, streaming may be required. Subscribing to streaming is the only way to receive real-time updates. If you determine that streaming is necessary for your application, we recommend explicitly enabling streaming mode by setting streaming: true on ldOptions.

Example code shows how to configure streaming explicitly.

Access flag values

After your code has initialized the React Web SDK, your primary means to access flag evaluation values is through our variation hooks.

Example code shows usage of useBoolVariation.

Making feature flags available to this SDK

You must make feature flags available to client-side SDKs before the SDK can evaluate those flags. If an SDK tries to evaluate a feature flag that is not available, the context will receive the fallback value for that flag.

To make a flag available to this SDK, check the SDKs using Client-side ID checkbox during flag creation, or toggle on the option in the flag’s right sidebar. To make all of a project’s flags available to this SDK by default, check the SDKs using Client-side ID checkbox on your project’s Flag settings page.

Configuration options

The createLDReactProvider function takes two required parameters: a client-side ID and an initial context. You can optionally specify a third LDReactProviderOptions parameter that lets you further configure your provider.

Hooks

The React Web SDK offers eight custom hooks.

Single-flag hooks

There are four single-flag hooks:

• useBoolVariation
• useStringVariation
• useNumberVariation
• useJsonVariation

These typed single-flag hooks re-render only when that specific flag changes.

We recommend using these hooks for evaluating individual flags. They are explicitly typed, with no generic type parameter needed.

The naming convention aligns with the LaunchDarkly React Native SDK and other LaunchDarkly SDKs, making the API consistent across platforms.

Example usage code is provided.

Single-flag hooks with full evaluation detail

There are four single-flag hooks that provide full evaluation details:

• useBoolVariationDetail
• useStringVariationDetail
• useNumberVariationDetail
• useJsonVariationDetail

These single-flag hooks return the full evaluation detail, including value, variationIndex, and evaluation reason, re-rendering only when that specific flag changes.

Use these hooks when you need the evaluation reason but don’t want to subscribe to every flag change.

Example usage code is provided.

Example app

For a working single-page app with React and react-router, use this example app.

Events

In v4.0 and later of the React Web SDK, the typed variation hooks and variation detail hooks send an evaluation event each time they evaluate a flag. To disable sending events, set the sendEvents configuration option to false.

Event behavior with the deprecated useFlags hook

The useFlags hook is deprecated in v4.0. If you are still using useFlags, the following event behavior applies:

• In versions 2.27 and later, the SDK sends an evaluation event when your app accesses a flag from the flags object returned by useFlags, and when you call a variation method on the LDClient.
• In versions 2.26 and earlier, you must make variation calls directly to send evaluation events.

If you are using Experimentation, confirm that reactOptions.sendEventsOnFlagRead is set to true or is not specified. Setting it to false prevents evaluation events from being recorded.

Do Not Track and ad blocking software

The React Web SDK respects the Do Not Track header. If an end user has Do Not Track enabled in their browser, the SDK does not send analytics events for flag evaluations or metrics to events.launchdarkly.com. To learn more, read Browser privacy settings block analytic events to LaunchDarkly.

In addition, ad blocking software may block analytics events from being sent. This does not impact feature flag evaluations. To learn more about the events SDKs send to LaunchDarkly, read Analytics events.

Flag keys and the deprecated useFlags hook

The useFlags hook is deprecated in v4.0. We recommend migrating to the typed variation hooks. The information in this section only applies if you are still using useFlags.

LaunchDarkly primarily identifies feature flags by a key which must contain only alphanumeric characters, dots (.), underscores (_), and dashes (-). These keys are used in the SDKs to identify flags, and in LaunchDarkly’s REST API.

However, in JavaScript, accessing keys containing . and - requires the bracket operator. Instead of requiring this, the React Web SDK automatically changes all flag keys to camel case by default when you use useFlags. A flag with key dev-flag-test is accessible as flags.devFlagTest.

Automatically changing flag keys to camel case poses some problems:

• It is possible to induce a key collision if there are multiple LaunchDarkly flag keys which resolve to the same camel-case key. For example, dev-flag-test and dev.flag.test are unique keys in LaunchDarkly, but the React Web SDK changes them to the same camel-case key.
• If a flag key contains three or more capital letters in a row, the React Web SDK automatically converts all letters between the first and last capital letter to lower case. For example, the SDK converts a flag with the key devQAFlagTest to devQaFlagTest. If you use devQAFlagTest with the useFlags() hook, the SDK will not find the flag.
• LaunchDarkly’s code references tool expects your source code to reference the exact key, not a camel-case equivalent. The tool does not detect keys that were automatically changed to camel-case. However, you can configure an alias to ensure that the code references tool detects the camel-case equivalents. To learn more, read Find flag aliases.
• Because the camel-case functionality is implemented in the React Web SDK instead of in the underlying JavaScript SDK, the underlying client object and functionality provided by the JavaScript SDK reflect flag keys in their original format. Only React-specific contexts such as your injected props use camel case.

To disable the SDK’s automatic camel-case feature, set the useCamelCaseFlagKeys option to false when you initialize the SDK. Like useFlags, this option is deprecated and will be removed in a future major version. The typed variation hooks always use the original flag key, so they are not affected by this option.

Example code shows how to disable the automatic camel-case feature.

With this option in place, you can access your dev-flag-test flag using bracket notation, for example, flags['dev-flag-test'].

If you keep the automatic camel-case feature enabled and you want to use LaunchDarkly’s code references tool, you can configure alias support to find camel-cased flags. To do so, use the value camelCase for the alias settings.

Multi-environment support

The React Web SDK supports multiple LaunchDarkly environments in the same React tree. Each environment gets its own React context, provider, and client. Hooks read from whichever context you pass.

Example code is provided.

Each client’s lifecycle, including identify(), is independent. Call it on each client when the user context changes.

Troubleshooting

This section describes common issues you might encounter when using the React Web SDK and how to resolve them.

Network error

If your application logs show the error LaunchDarklyFlagFetchError: network error, there may be a problem with network connectivity between your SDK and LaunchDarkly.

For steps to resolve this issue, read the LaunchDarkly Knowledge Base article Error “LaunchDarklyFlagFetchError: network error”.

CORS errors in local development

If you see CORS errors in the browser while using the ldcli dev-server, check your SDK configuration. The React Web SDK must use your project key as the credential and all service endpoints must point to http://localhost:8765.

If you use a client-side ID instead of the project key, the SDK connects to LaunchDarkly rather than the dev-server. This prevents the SDK from retrieving local flag values and can produce CORS errors.

React Server Component support

As of version 4.0 of the React Web SDK, React Server Components are supported. You can perform flag evaluation in React Server Components.

This behavior is available as a lightweight wrapper around a server-side SDK that supports enabling frontend changes.

You must initialize a separate server-side SDK to interface with React Server Component features. To learn more about the server-side SDKs that support React Server Components, read React Server Component version compatibility.

Quick links

React Server Component support is available as part of the open-source React Web SDK. In addition to this reference guide, we provide React Server Component-specific source, API reference documentation, and a sample application:

• API documentation: API docs
• GitHub repository: js-core
• Sample application: hello-react-server
• Published module: npm

React Server Component version compatibility

These behaviors work with the following React versions:

• React version 19.0.0 or higher

Create a wrapped server-side SDK client

This functionality wraps a server-side SDK and makes flag values available to React Server Components on a per-request basis.

Example code is provided.

Unique behaviors

Several behaviors are only available as part of React Server Component support.

createLDServerSession and useLDServerSession

This creates a per-request evaluation scope by binding a server SDK client to a specific context. The session is cached using React’s cache() API, so each request gets its own isolated instance. This also enables useLDServerSession() to retrieve the session from nested React Server Components.

Example code is provided.

createLDServerWrapper

This functions identically to createLDServerSession, but does not cache the session. Use this when you want manual lifecycle control or to avoid React’s cache() API.

This is an advanced behavior. Sessions created with createLDServerWrapper are not retrievable by useLDServerSession(). Instead, you must pass the session through props or module scope yourself.

Example code is provided.

Supported features

React Server Component support is available for the following LaunchDarkly SDK features:

• Bootstrapping
• Evaluating flags

Original source

Overview

This topic explains how to use the change history tab to restore a feature flag to a previous version.

Flag versions in change history

You can change a feature flag to a previous version.

Versions increment based on your actions. For example, if you are on version 5 and restore version 3, version 3 is brought forward and becomes version 6. The restore workflow shows version numbers, code diffs, and a preview of the new version. You cannot restore a version that is identical to the current version. If you try to restore an identical version, the diff is abbreviated to only show the updated timestamps and version numbers, and restoring is disabled.

To restore a previous version, visit the change history page.

Limitations

Flag versions are limited to flag configuration changes in the current environment, not flag variations or global flag settings. There are additional restrictions if a flag is part an experiment, rollout, or scheduled change. Here is a list of limitations for restoring previous flag versions:

• You can only restore states that existed within the last 30 days
• You can’t restore a version with an expired target date. For example, if the current date is June 1, 2026 and you attempt to restore a version that had a change scheduled to take effect on May 25, 2026, you cannot restore this version because the date of the scheduled change has already passed.
• You can’t roll back to states controlled by experiments, guarded rollouts, or progressive rollouts

Restore a previous flag version

Here’s how to restore a previous flag version:

1. Navigate to the flag’s change history page and find the version you want to restore. Versions that can be restored are indicated with a button that has “Restore previous version” hover text.
2. Click the version restore button in the row for the version you wish to restore. A code diff appears showing the changes between the current version and the version you intend to restore.
3. Verify that the changed version does what you expect and click Stage this version. A preview appears.
4. Click Review and save. A confirmation dialog appears.
5. Type the environment’s name to confirm and click Save changes.

The earlier flag version is now the current version.

Original source

This feature is in Early Access
LaunchDarkly’s observability features are publicly available in early access. Enable observability in the billing page.
They currently require the LaunchDarkly
observability SDKs
and the JavaScript, React Web, or Vue SDK.
If you are interested in participating in the Early Access Program for our upcoming observability plugins for server-side SDKs,
sign up here
.

Overview

This topic explains how to send traces, metrics, and logs from the
Datadog Agent
to LaunchDarkly’s observability features.
LaunchDarkly’s OpenTelemetry Collector includes a Datadog-compatible receiver. If you already run the Datadog Agent in your infrastructure, you can configure it to send APM traces, metrics, and logs to LaunchDarkly without changing your application instrumentation. Once received, this telemetry is available in the
Traces
,
Logs
, and observability dashboards in the LaunchDarkly UI.

Prerequisites

Before you configure Datadog Agent ingestion, you must:

• Have LaunchDarkly observability enabled for your project
• Have the
  Datadog Agent
  v6.0 or later installed and running in your infrastructure
• Know your LaunchDarkly client-side ID
  To find your client-side ID:
  • In the LaunchDarkly UI, click the project dropdown to open the project menu.
  • Select
    Project settings
  • Click
    Environments
  • Find the environment you want to use and copy the
    Client-side ID
    value.

Configure the Datadog Agent

To send telemetry to LaunchDarkly, configure the Datadog Agent to use LaunchDarkly’s Datadog-compatible endpoint. You can replace the standard Datadog intake, or send data to both Datadog and LaunchDarkly simultaneously using dual shipping.

Endpoint:
otel.observability.app.launchdarkly.com:8126

Configure using the agent configuration file

To configure the Datadog Agent using the
datadog.yaml
configuration file, include these lines:

datadog.yaml configuration
apm_config:
  enabled: true
  apm_dd_url: http://otel.observability.app.launchdarkly.com:8126

logs_config:
  logs_dd_url: otel.observability.app.launchdarkly.com:8126
  use_http: true

dd_url: http://otel.observability.app.launchdarkly.com:8126

Configure using environment variables

If you run the Datadog Agent in a container, you can use environment variables to provide the configuration:
Environment variable configuration
$ DD_APM_ENABLED=true
$ DD_APM_DD_URL=http://otel.observability.app.launchdarkly.com:8126
$ DD_DD_URL=http://otel.observability.app.launchdarkly.com:8126

Configure using Docker Compose

If you run the Datadog Agent as a Docker container, add the configuration to your
docker-compose.yml
file:

docker-compose.yml configuration
services:
  datadog-agent:
    image: gcr.io/datadoghq/agent:latest
    environment:
      - DD_APM_ENABLED=true
      - DD_APM_DD_URL=http://otel.observability.app.launchdarkly.com:8126
      - DD_DD_URL=http://otel.observability.app.launchdarkly.com:8126
      - DD_API_KEY=placeholder

DD_API_KEY is required
The Datadog Agent requires a
DD_API_KEY
value to start, even when routing to a non-Datadog endpoint. You can use any non-empty placeholder string. LaunchDarkly does not validate or use this value.

Sending data to both Datadog and LaunchDarkly

The examples above replace the default Datadog intake with LaunchDarkly’s endpoint. If you want to continue sending data to Datadog while also sending it to LaunchDarkly, you can configure the Datadog Agent to dual ship telemetry to both destinations.
Dual shipping lets you keep your existing Datadog dashboards, alerts, and workflows while also using LaunchDarkly’s observability features and guarded rollouts.
To learn how to configure dual shipping, read
Dual Shipping
in the Datadog documentation.
When configuring dual shipping, use
http://otel.observability.app.launchdarkly.com:8126
as the additional endpoint for APM traces, metrics, and logs.

Associate telemetry with your LaunchDarkly project

LaunchDarkly uses the
launchdarkly.project_id
resource attribute to route telemetry to the correct project. Set this to your LaunchDarkly client-side ID.
You can set this attribute in your application’s OpenTelemetry SDK configuration, or use the
OTEL_RESOURCE_ATTRIBUTES
environment variable for services that send data through the agent:
Environment variable
export OTEL_RESOURCE_ATTRIBUTES="launchdarkly.project_id=YOUR_CLIENT_SIDE_ID"
Alternatively, if you use the
OpenTelemetry Collector
in front of the Datadog Agent, you can inject this attribute using a
resource
processor. To learn more, read
OpenTelemetry in server-side SDKs
.

Attaching feature flag context to traces

To use Datadog trace data with LaunchDarkly features like
guarded rollouts
and
autogenerated metrics
, your traces must include feature flag evaluation data. LaunchDarkly uses this data to correlate traces with specific flag evaluations and contexts.
You can attach feature flag context to your Datadog traces by creating a custom
SDK hook
. The hook instruments each flag evaluation as a child span on your existing Datadog traces, adding attributes that LaunchDarkly uses to connect traces to flag evaluations.
The hook must set the following span attributes on each flag evaluation:

• Attribute | Description
• feature_flag.key
  • The key of the evaluated flag.
• feature_flag.context.id
  • The fully-qualified key of the LaunchDarkly context.
• feature_flag.contextKeys
  • A JSON object mapping each context kind to its key, for example {"user":"user-123"}.
• feature_flag.provider.name
  • Set to LaunchDarkly.
• feature_flag.result.value
  • The string representation of the evaluation result.

Go example

This example uses a
BeforeEvaluation
hook to start a Datadog span with flag metadata, and an
AfterEvaluation
hook to record the result and finish the span.
Expand Go hook implementation

Configuring the Datadog tracer

Configure the Datadog tracer in your application to send traces to LaunchDarkly’s Datadog-compatible endpoint. Set the
X-LaunchDarkly-Project
global tag to your LaunchDarkly project ID so that traces are routed to the correct project:
Go tracer configuration

import "github.com/DataDog/dd-trace-go/v2/ddtrace/tracer"
...
tracer.Start(
  tracer.WithAgentURL("http://otel.observability.app.launchdarkly.com:8126"),
  tracer.WithService("your-service-name"),
  tracer.WithEnv("production"),
  tracer.WithGlobalTag("X-LaunchDarkly-Project", "YOUR_PROJECT_ID"),
)
defer tracer.Stop()

Using flag data with guarded rollouts

After you configure the hook and tracer, LaunchDarkly automatically processes your Datadog trace data and associates it with the feature flags and contexts in your evaluations. This enables you to:

• Use
  autogenerated OpenTelemetry metrics
  , such as HTTP error rates and latencies, with
  guarded rollouts
• Monitor how flag changes impact your application performance in
  Traces
• Correlate errors and latency regressions with specific flag evaluations and context attributes
  To learn more about setting up guarded rollouts, read
  Creating guarded rollouts
  .

What data is collected

The Datadog Agent sends the following telemetry types to LaunchDarkly:

• Traces
  : APM traces from your instrumented services, visible in
  Traces
• Metrics
  : Infrastructure and application metrics
• Logs
  : Application logs collected by the agent log collection feature, visible in
  Logs

Verify that data is being received

After you configure the Datadog Agent, telemetry begins flowing to LaunchDarkly.
To verify that traces are being received:

• In the LaunchDarkly UI, expand
  Observe
  in the left navigation.
• Click
  Traces
• Look for traces from your Datadog-instrumented services.
  To verify that logs are being received:
• In the LaunchDarkly UI, expand
  Observe
  in the left navigation.
• Click
  Logs
• Look for logs from your services.
  It may take a few minutes for data to appear after you first configure the agent.

Filtering ingested data

You can configure ingestion filters to control which logs are stored in LaunchDarkly. This is useful for reducing noise or staying within your observability quotas.
To learn more, read
Filters
.

Original source

Guarded rollouts availability

Guarded rollouts are available to customers on a Guardian plan. To learn more, read about our pricing. To upgrade your plan, contact Sales.

All LaunchDarkly accounts include a limited trial of guarded rollouts. Use this to evaluate the feature in real-world releases.

Overview

This topic explains how to monitor metrics on flag and AI Config releases and configure LaunchDarkly to take action on the results.

An active guarded rollout on a flag change.

When you begin serving a new flag or AI Config variation, such as when you toggle a flag on or update the default rule variation, you can add a guarded rollout. A guarded rollout progressively increases traffic to the new variation while monitoring selected metrics for regressions until the rollout reaches 100%. If LaunchDarkly detects a regression before the rollout reaches 100%, it can pause the rollout and sends a notification.

In a guarded rollout, each metric appears in its own tile. Each tile includes a difference chart that shows how the new variation compares to the original variation over time. The dark grey line represents the absolute difference, and the shaded grey area represents the absolute difference’s confidence interval.

LaunchDarkly identifies a regression when sequential testing determines that the absolute difference represents a statistically significant negative impact on a monitored metric.

On the chart, this occurs when the confidence interval falls entirely on the side of worse performance based on the metric’s success criteria. For lower-is-better metrics, the confidence interval lies above zero. For higher-is-better metrics, the confidence interval lies below zero.

Legacy relative difference

Previous versions of guarded rollouts supported relative difference, which measured change as a percentage relative to the original variation. Guarded rollouts now use absolute difference for all analyses. Relative difference is no longer supported.

When a regression is detected, the metric tile highlights the regression. If automatic rollback is enabled, LaunchDarkly also rolls back the release.

Minimum context requirement for guarded rollouts

A new flag or AI Config variation must be evaluated by a minimum number of contexts during each step of a guarded rollout. If this requirement is not met, LaunchDarkly automatically rolls back the change.

Guarded rollouts are one of several options that LaunchDarkly provides to help you release features safely and gradually. To learn about other release options, read
Releasing features with LaunchDarkly.

You can create a guarded rollout on any targeting rule, as long as no other guarded rollouts, progressive rollouts, or experiments are running on the flag or AI Config, and the flag is not a migration flag.

View flags with guarded rollouts

To view flags that currently use or previously used a guarded rollout, click
Guarded rollouts in the left navigation.

Use the
Filters menu to filter the list by rollout status. Navigate to the flag’s
Monitoring tab to
view and manage the rollout.

AI Configs with guarded rollouts do not appear on the
Guarded rollouts list.

Metrics and guarded rollouts

Metrics track system health indicators and end-user behavior, such as errors, latencies, clicks, and conversions. When you attach metrics to a flag or AI Config change, you can measure how the new variation affects those metrics during the rollout.

You can connect metrics to LaunchDarkly in several ways:

Use one of our
metrics integrations.

Call the
metric import API.

Use a LaunchDarkly SDK to
send custom events and
connect them to metrics.

Enable OpenTelemetry in a LaunchDarkly SDK and send traces to LaunchDarkly to
autogenerate metrics.

To learn more, read
Metrics.

Regressions

When you attach metrics to a flag or AI Config and start a guarded rollout, LaunchDarkly compares the performance of the new variation to the original variation.

A regression is a statistically significant negative impact on a monitored metric. Release Guardian determines this by measuring the absolute difference between the new and original variations and applying sequential testing.

You can configure LaunchDarkly to notify you of a regression, or to notify you and automatically roll back the release when a regression is identified.

To learn how to investigate regressions in your guarded rollouts, read
Guarded rollout errors.

Original source

Release notes

• January 13, 2026: Publishes a topic on using the developer toolbar. Affected topics: Using the LaunchDarkly developer toolbar

• January 12, 2026: Publishes a topic about choosing a statistical methodology for experiments. Affected topics: Choosing a statistical methodology

• January 12, 2026: Updates the data saving mode EAP topic with information about using the .NET (server-side) SDK version 8.11. Affected topics: Data saving mode

• January 9, 2026: Adds documentation for deep linking to session search queries and linking to specific sessions by ID with timestamps. Affected topics: Session replay

• January 9, 2026: Updates Android observability SDK privacy settings: renames maskSensitive to maskBySemanticsKeywords, changes maskText default to false, and removes maskAdditionalMatchers option. Affected topics: Android SDK observability reference, Configuration for session replay

• January 7, 2026: Updates the testing flag changes topic with information about previewing the percentage of contexts that will receive a variation. Affected topics: Testing changes to flag targeting

Original source

This feature is in Early Access

LaunchDarkly’s observability features are publicly available in early access. Enable observability in the billing page.
They currently require the LaunchDarkly observability SDKs and the JavaScript, React Web, or Vue SDK.
If you are interested in participating in the Early Access Program for our upcoming observability plugins for server-side SDKs, sign up here.

Overview

This topic describes the project-level settings available for sessions, errors, logs, and traces.
In the left navigation of the LaunchDarkly UI, expand Observe to view them.
To view or update project-level settings for these features:

• Click the project dropdown to open the project menu.
• Select Project settings.
• Click Observability. The Observability settings page appears.

The following sections describe the available settings.

Session settings

You can configure the following settings for sessions in your project:

• Excluded users. This setting excludes sessions from particular end users, based on their context key or email address.
• Rage clicks. These settings adjust the sensitivity for detecting “rage clicks,” or occasions when end users repeatedly click an element in your application, indicating frustration. You can set the Elapsed time, Radius, and Minimum clicks. These settings control whether a search for session replays that uses the has_rage_clicks attribute will return a given session. By default, LaunchDarkly considers end-user activity a rage click when there exists a two-second or longer period in which an end user clicks five or more times within a radius of eight pixels.
  Click Save to save your settings.

Error settings

You can configure the following settings for errors in your project:

• Sourcemaps. If you have uploaded sourcemaps, you can view them here.
• Auto-resolve stale errors. When enabled, this setting automatically sets the status of an error to “Resolved” after the time period you select.
  Click Save to save your settings.

Filters

Filters help you manage the ingestion of sessions, errors, logs, or traces that you send to LaunchDarkly. This is useful if you know certain signals which are not relevant to your application or are not actionable. Any excluded signals do not count against your observability quotas.
To configure ingestion filters:

• Navigate to the Observability project settings page.
• From the Filters section, click Edit next to the type of signal you want to configure.
• (Optional) Configure filter rules to manage ingestion of sessions, errors, logs, or traces.
• (Optional) Set the Max ingest per minute. This setting rate limits the maximum number of data points ingested in a one-minute window. For example, you may configure a rate limit of 100 per minute. This lets you limit the number of data points recorded in case of a significant spike in use of your application.
• Click Save.

Rule evaluation order

Rules are evaluated in order, from top to bottom. Drag and drop the rules to reorder them to fit your project’s needs. The first enabled rule that matches the criteria applies its filter operation and rate.

Rules

To add a filter rule:

• Click Add rule.
• Set a rule name.
• Review the filter rule operation. Exclusion rules are used for sessions, errors, and logs. Inclusion rules are used for traces. You cannot change these settings.
• Set a query:
  • Click the Filter… placeholder and select an attribute from the dropdown. For example, you can filter sessions based on active_length.
  • Select an operator from the dropdown. For example, you can filter by greater than, >.
  • Enter a value for your expression. For example, you can enter 8s for eight seconds.
• Set the rules rate (%). For each signal that LaunchDarkly receives, it makes a randomized decision according to the rules rate whether to apply the include or exclude filter operation.
  • For example, if an exclusion rule has a 20% rate, then 20% of the signals that match the rule’s query are excluded and the remaining 80% are included.
• Set the rule On or Off to enable or disable the rule.
• Click Save.

Records with no matching rules

If a signal does not match any rules query, then it is included by LaunchDarkly.

Here is an example of multiple log filter rules:
An example of multiple log filter rules.

Here is how rule order controls rule evaluation:

• Logs with level=ERROR and service_name=example-service are always included, the first rule matches, therefore the second and third rule are not reached.
• Logs with level=DEBUG and service_name=example-service are always excluded, the first rule is skipped, the second rule matches, therefore the third rule is not reached.
• Logs with level=INFO and service_name=example-service are 80% excluded and 20% included, the first and second rule are skipped, and the third rule matches.
• Logs with level=INFO and service_name=new-service are always included, all three rules are skipped, therefore the log is ingested.

Original source

Here’s what’s new

A cleaner, more focused navigation reduces noise and helps you move faster.

It’s been about a year and a half since we introduced a new and improved LaunchDarkly experience, a major redesign that unified environments, improved navigation, and created more clarity across the app.

Since then, our platform has expanded, and our navigation has expanded with it. Over time, the number of items and icons multiplied, and things started to feel a little overwhelming. Our customers provided consistent commentary:
“I can’t see what matters most.”
“The shortcuts are buried.”
“It’s powerful, but it’s a lot.” We prioritized a refresh based on this feedback.

This update makes the navigation cleaner, more focused, and better aligned with how you actually work. It helps keep what’s important in view and gives you back control of your screen real estate.

Here’s what’s new:

• Collapsible sections so you can keep open the sections you interact with the most and hide what you don’t. Your layout will stay exactly how you leave it, even on page refresh.
• Simplified visuals with fewer icons and improved spacing, making it easier to scan the navigation and find what you’re looking for.
• Shortcuts moved up for faster access to your most frequently visited flags. If you haven’t tried this feature before, Shortcuts let you bookmark filtered views of your flags dashboard for quick access to the flags you work with most.
• A refined Create action that remains easy to find but no longer competes with key actions on the page.
• An improved search experience that offers quick, keyboard-friendly access to any part of the platform.

These changes are now available to all LaunchDarkly users.

This work builds on the progress we’ve made over the past year and a half. It reduces visual noise, adds flexibility, and helps teams move faster and stay focused. We’re excited for you to experience it, and we’d love to hear what you think. Share your reaction with us at [email protected].

Original source