Is LaunchDarkly down right now?

While you wait: the LaunchDarkly incident checklist

1. Name the dependency precisely. LaunchDarkly is your observability dependency. Identify which of these surfaces is actually in the production path: telemetry ingestion, queries, dashboards, alerting and incident evidence.
2. Confirm the affected path. Use LaunchDarkly's component and incident detail, then compare the provider with an independent uptime check, raw application logs or infrastructure metrics before treating silence as health.
3. Bound every retry. Cap concurrency, use exponential backoff and retain idempotency where applicable. An upstream incident should not become a retry storm against LaunchDarkly or your own services.
4. Use the rehearsed fallback. For this dependency, keep releases possible by making nonessential telemetry uploads best-effort and switch responders to independent signals. Do not invent a new failover path during the outage.
5. Verify recovery end to end. A green LaunchDarkly status is the start of validation: mark the visibility gap and expect delayed ingestion or alert bursts as pipelines recover.

What breaks when LaunchDarkly has issues

LaunchDarkly sits in the monitoring layer. An incident can affect telemetry ingestion, queries, dashboards, alerting and incident evidence; the exact blast radius depends on the components, regions and features your production path uses. Treat the official component timeline as evidence, compare it with your own independent probes, and communicate the user-visible effect rather than saying the whole vendor is simply “down.”