LaunchDarkly Status: Is LaunchDarkly Down?
For live status, go straight to the source: status.launchdarkly.com. This page keeps a plain-English record of what recent LaunchDarkly incidents actually required of customers, something their status page tends to describe one update at a time.
Full disclosure: we're ShipSilently, a LaunchDarkly alternative, so we have a horse in this race. Every incident fact below is transcribed from LaunchDarkly's own public status page (May–July 2026, captured 2026-07-11, times PDT), with quotes verbatim; check them against the source.
How to check whether LaunchDarkly is down
- Official status page: status.launchdarkly.com: current incidents, per-component status, uptime history, and a Subscribe button for notifications. Federal instance: status.launchdarkly.us.
- Your application logs: during SDK-affecting incidents, LaunchDarkly's own guidance is to search logs for "giving up permanently," "Invalid SDK key," "unauthorized," "not authorized," or "401". Services that logged these may be silently disconnected (receiving no flag updates and sending no events) even after the incident resolves.
- Flag behavior: if toggles in the dashboard aren't reaching your services, your SDKs may be serving stale state on a dead connection. This can persist after the status page turns green (see July 10 below).
July 10, 2026: three incidents in one morning, and a restart-your-fleet remediation
On July 10, 2026, LaunchDarkly's status page logged three overlapping incidents: "Mobile and Server SDKs are intermittently down" (from 9:00 AM), "LaunchDarkly UI is down and flag evaluation errors are occurring" (9:16–10:48), and "Web application unavailable and flag delivery evaluations have elevated failure rate" (10:10–11:19). For part of that window, customers could neither trust flag delivery nor reach the dashboard to flip a kill switch.
The lasting damage came from how their SDKs handled it. The services returned 401/unauthorized errors that a restart clears (no key rotation was advised), so the keys were still valid, and the SDKs concluded they were dead and gave up for good. From the status page update at 4:32 PM PDT, verbatim:
Affected SDKs emit messages—varying by language—that contain any of the following: "giving up permanently," "Invalid SDK key," "unauthorized," "not authorized," or "401." Any service that logged these messages may be unable to receive flag updates or send event data until it is restarted. Here are the recommended actions for each affected application: - If you use server-side SDKs, please restart the application to re-establish its connection to LaunchDarkly. - If you use the Relay Proxy, please restart the Relay Proxy to re-establish connections. … - If this does not resolve the issue for an affected application (e.g. you still see the log messages from above), please log a support ticket and we will follow up with you directly to assist with remediation.
That left every affected team doing the vendor's cleanup: identify disconnected services from log strings, restart Relay Proxies first, then restart application fleets, and open a support ticket if services still wouldn't reconnect. Until then, affected services received no flag updates (kill switches flipped in the dashboard silently didn't propagate) and sent no event data.
Their UI-incident update also pointed customers at a dedicated incident page for flag delivery and event ingest monitoring: status.launchdarkly.com/incidents/chywwz01ptb0.
We wrote up why "giving up permanently" on a 401 is a design flaw, and the retry policy that makes restarts unnecessary, in Your Feature Flag SDK Should Never Ask You to Restart Production.
LaunchDarkly incident history (May – July 2026)
Transcribed from status.launchdarkly.com. Their page listed 8 incidents in the first 10 days of July, 6 in June, and 7 in May; the tables below show the ones their history page displayed in full. Most were scoped or brief. The pattern worth noticing is how often flag delivery, event ingestion, and the dashboard appear.
July 2026
| Date (PDT) | Window | Incident |
|---|---|---|
| Jul 10 | 10:10 – 11:19 | Web application unavailable and flag delivery evaluations have elevated failure rate Resolution notes told server-side SDK and Relay Proxy customers they "might need to restart" to re-enable SDK connections; services that logged the affected messages before 9:13 AM PT "may be unable to receive flag updates and will be unable to send events to LaunchDarkly until they are restarted." |
| Jul 10 | 09:16 – 10:48 | LaunchDarkly UI is down and flag evaluation errors are occurring Dashboard unavailable while flag evaluation errors were ongoing, a window where you could neither trust the SDKs nor reach the kill switch. |
| Jul 10 | from 09:00 | Mobile and Server SDKs are intermittently down SDKs logged "giving up permanently," "Invalid SDK key," "unauthorized," "not authorized," or "401" and stopped receiving flag updates and sending events until manually restarted. Detailed below. |
| Jul 8 | 11:03 – 12:41 | Frequentist experiments cannot be saved or started |
| Jul 7 | ~5 min delay, 7:13 – 7:53 AM | Delays in Experimentation and Guarded Rollout results No data lost per the status page. |
| Jul 6 | afternoon | High volume of error alerts related to flag delivery network "All error rates have normalized." |
| Jul 6 | 07:33 – 08:52 | Verification emails not being sent |
| Jul 3 | 07:29 – 09:06 | Elevated error rates on event data ingestion endpoints |
June & May 2026 (as displayed; 3 more in June and 4 more in May were collapsed)
| Date (PDT) | Window | Incident |
|---|---|---|
| Jun 17 | 12:43 – 18:30 | LaunchDarkly.com and LaunchDarkly.com/docs unavailable for some |
| Jun 15 | 10:02 – 10:38 | Observability OpenTelemetry Ingest Delay |
| Jun 8 – Jun 13 | ≈5 days | Delays in event ingestion Opened Jun 8 13:46, resolved Jun 13 06:52. Five days end to end. |
| May 22 | 11:40 – 12:41 | Issue with Slack notifications for Segment approvals |
| May 19 | results delayed 6:58 – 7:52 AM | Event Ingestion Delays No data lost per the status page. |
| May 15 | 17:03 – 18:13 | Delayed processing of Session Replay and Error data |
What to do when LaunchDarkly is down
- Confirm scope on the status page. Flag delivery incidents matter far more than dashboard or ingestion ones.
- Don't panic-toggle. If flag delivery is degraded, changes you make may propagate to some services and not others. Prefer waiting over creating split-brain state. This is why safe flag defaults matter more than any vendor's SLA.
- After recovery, check your logs for the strings above. Their SDKs can stay silently disconnected after the status page turns green.
- Follow their restart order: Relay Proxy first, then (if still affected) the applications behind it; client-side SDKs reconnect as they restart. Open a support ticket for anything still logging auth errors.
- Afterwards, audit your defaults. Every flag call should carry a default that fails to the old, known-working behavior. An outage where flags freeze is survivable; an outage where flags freeze wrong is an incident of your own.
Steps 3 and 4 are the part we'd push back on. An SDK that has to be restarted by a human after its vendor's transient auth failure has a terminal state where a retry loop should be. ShipSilently's SDKs reconnect with jittered exponential backoff after any failure, including 401s, keep serving last-known-good values throughout, and need nothing from you when the control plane recovers. Here's the full design.
FAQ
Is LaunchDarkly down right now?
Check LaunchDarkly's official status page at status.launchdarkly.com, which lists current incidents, component status, and history. This page tracks notable past incidents and what they required of customers; it is not a live monitor.
Where is LaunchDarkly's official status page?
status.launchdarkly.com (and status.launchdarkly.us for the federal instance). You can subscribe there for incident notifications.
Why did LaunchDarkly SDKs need a restart after the July 10, 2026 outage?
During the incident, LaunchDarkly's services returned 401/unauthorized errors that a restart clears, with no key rotation advised, which indicates the affected SDK keys were still valid. Their SDKs treat auth errors as permanent (they log "giving up permanently" and stop reconnecting), so once the incident ended, affected server-side SDKs and Relay Proxies stayed disconnected until the host application was manually restarted.
How often does LaunchDarkly have incidents?
Per their own status page: 8 incidents in the first 10 days of July 2026, 6 in June (including a five-day event-ingestion incident), and 7 in May. Most were minor or scoped to specific features; the July 10 cluster affected flag delivery and SDK connectivity.
What should my application do when LaunchDarkly is down?
Serve safe defaults or last-known-good flag values, never block startup on the flag service, and prefer SDKs that auto-recover instead of giving up permanently. If your flag vendor's outage remediation is "restart your applications," your architecture (or your vendor) has a gap.
Tired of doing your vendor's incident response?
ShipSilently is a $49/month flat-priced, edge-native feature flag service whose SDKs have no "giving up permanently" branch. Compare it honestly (including where LaunchDarkly is ahead) on our LaunchDarkly comparison, or see the migration guide (most teams: under an hour, parallel run supported).
Sources
- Incident titles, time windows, and remediation text: transcribed from the status.launchdarkly.com incident history for May–July 2026, captured 2026-07-11. The screenshot above shows the July section of that history; the remaining rows come from the same capture. Quotes verbatim; times PDT as shown on their page.
- The flag delivery / event ingest incident page LaunchDarkly linked from its own July 10 update: status.launchdarkly.com/incidents/chywwz01ptb0.
- Pricing figures: Vendr purchasing data, compiled with dates and source links on our comparison page.
Spot an error? Email hello@shipsilently.com and we'll fix it.