How do we connect Datadog (or OpenTelemetry) to LaunchDarkly so we can monitor rollouts and alert on regressions?

Move fast on releases without signing up for 2am fire drills. Connecting Datadog and OpenTelemetry to LaunchDarkly gives you one control surface for both changing behavior in production and watching what happens in real time—so you can catch regressions early and, if needed, roll back automatically with no redeploys required.

Quick Answer: You connect Datadog or OpenTelemetry to LaunchDarkly by sending your metrics/events into those tools, linking them to specific feature flags, and configuring LaunchDarkly to monitor those metrics during rollouts. When a metric crosses a threshold, LaunchDarkly (or your APM trigger) can alert you or even auto-disable the flag.

Quick Answer: LaunchDarkly integrates with Datadog and OpenTelemetry so you can tie errors, latency, and business KPIs directly to feature flags. That lets you monitor rollouts by flag, alert on regressions, and even auto-rollback risky changes—without pushing a new deploy.

The Quick Overview

What It Is: A runtime connection between LaunchDarkly, Datadog, and OpenTelemetry that lets you observe feature rollouts through your existing monitoring stack and trigger alerts or rollbacks from real production signals.
Who It Is For: Engineering, SRE, and product teams that already rely on Datadog or OpenTelemetry and want feature-aware monitoring instead of generic “something broke” alerting.
Core Problem Solved: You can’t safely move fast if you can’t see which feature caused what. This integration links metrics to flags so you can monitor rollouts, catch regressions early, and reduce blast radius.

How It Works

You keep using Datadog or any OpenTelemetry-compatible backend as your observability layer. LaunchDarkly becomes the runtime control plane that knows which users see which flags, and which flags are currently rolling out.

At a high level:

Send telemetry to your observability stack.
Your app emits metrics, traces, and logs through OpenTelemetry SDKs or Datadog libraries as usual.
Make events/metrics feature-aware.
You attach feature context (flag key, variation, user segment) via LaunchDarkly SDKs or metadata in your telemetry so you can slice charts and alerts by flag.
Wire observability to LaunchDarkly.
You either:
- Configure metrics in LaunchDarkly to track rollout health using data from your app/telemetry, or
- Use Datadog (and other APM tools) to trigger LaunchDarkly flag changes when thresholds are breached.

From there, you can monitor rollouts in LaunchDarkly, in Datadog dashboards, or both—and automatically pause or roll back problematic features.

How It Works: Step‑By‑Step

1. Instrument your application

You need two pieces in place:

A LaunchDarkly SDK in your service (one of 25+ native SDKs).
A Datadog agent or OpenTelemetry SDK exporting to your preferred backend.

Typical server-side setup:

# Example high level, not exact commands
# 1. Add LaunchDarkly SDK
npm install launchdarkly-node-server-sdk

# 2. Add telemetry (Datadog or OTEL)
npm install dd-trace
# or OTEL packages for your language

Initialize both at app startup:

// Pseudocode for Node.js
import LDClient from 'launchdarkly-node-server-sdk';
import tracer from 'dd-trace';

tracer.init(); // Datadog

const ldClient = LDClient.init(process.env.LD_SDK_KEY);
await ldClient.waitForInitialization();

The result: your app can both evaluate feature flags at runtime and emit telemetry for every request.

2. Attach feature flag context to telemetry

To monitor rollouts and alert on regressions, your observability data has to know which flag state was active.

There are two main patterns.

Pattern A: Enrich telemetry with flag metadata

When you evaluate a flag, capture the result and attach it to traces/metrics:

const user = { key: userId };
const variation = await ldClient.variation('checkout-redesign', user, false);

// Use variation to control behavior…
if (variation) {
  // new code path
}

// Attach to your telemetry context
tracer.scope().active().setTag('ld.flag.checkout-redesign', variation);

In Datadog, you can now filter or group by ld.flag.checkout-redesign:true.

With OpenTelemetry, you’d attach attributes:

span.setAttribute('ld.flag.checkout-redesign', variation);

This gives you:

Dashboards that compare error rate or latency by flag variation.
Alerts scoped to “only when the flag is ON.”

Pattern B: Use LaunchDarkly metrics & events

LaunchDarkly can also ingest custom events you send via the SDK:

ldClient.track('checkout_completed', user, { amount: 59.99 });

You then configure metrics in LaunchDarkly that tie those events to flags, so LaunchDarkly can monitor rollout health directly.

3. Connect Datadog triggers to LaunchDarkly (for auto-rollback)

LaunchDarkly supports “flag triggers” from APM tools including Datadog. The pattern:

You configure a trigger in LaunchDarkly for a specific flag (for example, checkout-redesign).
You generate a trigger URL that, when called, changes the flag state (typically to OFF).
In Datadog, you set up a monitor and use that URL as the webhook when a threshold is breached.

Conceptually:

Metric: service.checkout.error_rate
Condition: > 2% for 5 minutes
Action: POST to LaunchDarkly trigger URL to disable the flag

So when error rate spikes for traffic on that flag, Datadog tells LaunchDarkly to flip the kill switch—no redeploy required.

This is the APM-driven version of what Guardian/Guarded Releases do directly inside LaunchDarkly: automatic pause or rollback when performance thresholds are exceeded.

4. Use OpenTelemetry for unified instrumentation

If you’re standardizing on OpenTelemetry, the flow is similar:

Instrument your service with OTEL SDKs for traces, metrics, and logs.
Attach LaunchDarkly flag attributes to spans/metrics.
Export OTEL data to your backend of choice (Datadog, Honeycomb, etc.).
Define alerts that call LaunchDarkly triggers or page the on-call.

Because OpenTelemetry is vendor-neutral, this gives you a single instrumentation layer and lets LaunchDarkly act as the runtime control plane on top.

5. Configure rollout monitoring in LaunchDarkly

Within LaunchDarkly, you can:

Define metrics tied to events: conversions, errors, latency, custom KPIs.
Configure monitoring windows from days down to minutes.
Track rollout health for a specific flag: see if metrics improve, stay flat, or regress as exposure increases.

Metrics can be configured via:

LaunchDarkly APIs
LaunchDarkly SDKs (via track)
Third-party integrations (for example, Sentry)
OpenTelemetry data that ultimately maps to events/metrics you’re tracking

This gives you another view of rollout safety alongside your Datadog dashboards.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Flag‑aware telemetry	Adds flag key/variation context to traces, metrics, and logs in Datadog or OTEL backends	See exactly which flag caused a regression
APM‑driven flag triggers	Lets Datadog and other APMs call LaunchDarkly to disable flags when thresholds are exceeded	Automated rollback without redeploys
LaunchDarkly metrics & monitoring	Tracks custom events and KPIs tied to flags over configurable windows	Monitor rollout health in real time, from minutes to days
Guarded/automated rollouts	Monitors performance thresholds and can pause or rollback features automatically	Reduce blast radius and 2am fire drills
Multi-tool visibility	Integrates with Datadog, Jira, ServiceNow, Slack, Microsoft Teams and more	Keep engineering and product on the same release surface

Ideal Use Cases

Best for high-risk rollouts: Because you can tie error rates, latency, and business metrics directly to the flag and automatically kill the feature if something breaks.
Best for teams consolidating observability: Because OpenTelemetry lets you standardize instrumentation while LaunchDarkly provides runtime control, so you watch and adjust the same change from one place.

Limitations & Considerations

You need consistent flag context in telemetry: If you don’t attach flag keys/variations to traces or events, your dashboards and alerts won’t be “flag-aware.” Make this part of your instrumentation standards.
Alert tuning still matters: Auto-rollback is powerful but only as good as your thresholds. Start conservative, test triggers in non-production, and validate that triggers only fire on real regressions.

Pricing & Plans

LaunchDarkly’s pricing depends on your scale (flags, environments, MAUs) and which capabilities you need (feature management, experimentation, observability, AI Configs).

Teams / Growth plans: Best for teams needing robust feature flags, progressive rollouts, and core integrations (including Datadog) to monitor changes safely.
Enterprise plans: Best for organizations needing advanced governance (policies, approvals, audit logs), experimentation, full observability SDK support, and automated rollback at global scale (45T+ flag evals/day, 99.99% uptime).

For exact pricing and which plan is right for you, you’ll want a tailored conversation with the LaunchDarkly team.

Frequently Asked Questions

How do we practically wire Datadog alerts to LaunchDarkly for auto‑rollback?

Short Answer: Create a LaunchDarkly trigger for your flag, then configure a Datadog monitor to call that trigger URL when a metric crosses your threshold.

Details:

In LaunchDarkly, open the flag you want to protect (for example, checkout-redesign).
Create a trigger and choose the action (usually “turn flag off” or “set rollout to 0%”).
Copy the generated trigger URL.
In Datadog, create or edit a monitor on the metric you care about (for example, service.checkout.error_rate).
In the alert configuration, add a webhook that POSTs to the LaunchDarkly trigger URL when the condition is met.

Now, when error rates spike during a rollout, Datadog will automatically flip the flag in LaunchDarkly—no code changes, no redeploys, reduced blast radius.

How does OpenTelemetry fit in if we’re already using Datadog?

Short Answer: Use OpenTelemetry as your instrumentation layer and Datadog as the backend; attach LaunchDarkly flag attributes in OTEL spans/metrics so Datadog dashboards stay flag-aware.

Details:

Instrument services with OpenTelemetry SDKs, not Datadog-specific libraries, so you have a portable signals layer.
Configure OpenTelemetry exporters to send data to Datadog.
Whenever you evaluate a flag with LaunchDarkly, add OTEL attributes like ld.flag.<flag-key> and variation information to spans and metrics.
In Datadog, you can now filter, group, and alert by those attributes.
Optionally, use Datadog monitors to trigger LaunchDarkly flag rollbacks the same way as a pure Datadog setup.

You keep Datadog’s dashboards and alerts, gain vendor-neutral instrumentation, and still use LaunchDarkly as the runtime control plane.

Summary

Connecting Datadog and OpenTelemetry to LaunchDarkly turns feature flags into fully observable, reversible production changes. You:

See exactly which flag caused a regression, not just that “something broke.”
Monitor rollout health with metrics tied directly to flags.
Use triggers and Guarded Releases to auto-pause or rollback features when thresholds are breached—no redeploys required.

It’s the same runtime surface for release, observe, and iterate—so you can move faster in production without expanding your blast radius.

Next Step

Get Started