On February 26, 2026, LaunchDarkly experienced yet another outage. The incident — titled "Issues with LaunchDarkly Application and Authentication" — left customers unable to access the LaunchDarkly UI and API. And this wasn't an isolated event.
We're not here to pile on. Outages happen. Every SaaS product has bad days. But when your feature flag provider is the system that controls what your users see, an outage isn't just an inconvenience — it's a production incident for your product.
Let's talk about what actually matters when it comes to feature flag reliability, and what you can do about it.
A pattern of incidents
Here's a timeline of publicly reported LaunchDarkly incidents from the past few months:
Issues with LaunchDarkly Application and Authentication
Customers unable to access UI and API
Flag Targeting Service Outage
Flag targeting service went down
Data Ingestion Delays
Flag usage metrics delayed for 2+ hours
Multiple Component Outage
Analytics, rollout processing, and polling API affected
Elevated Latencies
Event processing delays lasting 27+ days
Sources: status.launchdarkly.com, StatusGator, DownDetector. Incidents are based on publicly available information.
Why feature flag outages are different
When Slack goes down, your team switches to email. When your analytics provider hiccups, you check the dashboard tomorrow. When your feature flag provider goes down, the consequences can be immediate and severe:
You can't kill a broken feature
A bug slips through and you need to toggle it off? If your flag provider is unreachable, you're stuck shipping a hotfix the old-fashioned way.
Gradual rollouts freeze
You're rolling out a new checkout flow to 10% of users and something looks wrong. Can't adjust the percentage? Can't pause the rollout? Hope that 10% doesn't churn.
A/B tests return garbage data
If flag evaluations fail or fall back to defaults inconsistently, your experiment results are meaningless.
Your deployment workflow breaks
If your team depends on flags for deploy-release decoupling, a flag outage means nobody can safely ship.
The core problem: cloud-only flag evaluation
Most feature flag platforms evaluate flags on their servers, not yours. When your application needs to check if a flag is on or off, it makes a network call to the provider's API. If that API is down, slow, or unreachable, your flag evaluation either fails, times out, or returns a stale default.
LaunchDarkly's architecture does include client-side caching and streaming connections to reduce this dependency. Credit where it's due — they've invested heavily in resilience. But as February 2026 proved, even well-engineered cloud services go down.
The question isn't if your flag provider will have an outage. It's what happens to your application when it does.
What resilient flag evaluation looks like
Local evaluation by default
The most resilient flag evaluation happens locally, inside your application. No network call. No dependency on a third-party server being up. Your application downloads the full flag configuration on startup and evaluates flags locally.
Graceful degradation
When the sync connection drops, your application continues evaluating flags with the last known configuration. Not defaults. Not errors. The actual rules you configured, running locally. A 30-minute provider outage should have zero impact on your flag evaluations.
Fast sync, not real-time dependency
There's a difference between "flags update quickly" and "flags require a live connection." Polling every 30 seconds for config changes is pragmatic and resilient. Requiring a persistent streaming connection adds a failure mode.
Minimal attack surface
The fewer external dependencies in your flag evaluation path, the fewer things can break. A flag system that requires your application to talk to a CDN, a streaming service, and an API has three times the failure modes of one that just polls a single endpoint.
How ToggleTown handles this
We built ToggleTown with these principles from day one — not because we anticipated LaunchDarkly outages, but because we've been on the receiving end of third-party service failures too many times.
import { ToggleTown } from '@toggletown/sdk';
const client = new ToggleTown({
apiKey: 'your-api-key',
pollingInterval: 30000, // sync every 30s
});
// This is a local evaluation — no network call
const showNewCheckout = client.isEnabled('new-checkout', {
userId: user.id,
email: user.email,
});Side-by-side comparison
| ToggleTown | LaunchDarkly | |
|---|---|---|
| Flag evaluation | Local-first, always | Server-side + client SDK cache |
| Outage impact on your app | Zero — local evaluation continues | Depends on SDK fallback config |
| SDK languages | JavaScript, React, Node.js | 25+ |
| Pricing | Free up to 5 projects, $29/mo Pro | $10/seat/month + enterprise tiers |
| A/B testing | Included in Pro | Enterprise plan only |
LaunchDarkly has broader SDK coverage and deeper enterprise integrations. If you need flags in Go, Rust, Python, Ruby, .NET, and 20 other languages, they're the safer bet today. But if you're a JavaScript/TypeScript team, ToggleTown gives you the same core functionality with better resilience.
What you should do right now
Whether you use LaunchDarkly, ToggleTown, or something else, here's a practical checklist:
Test your fallback behavior
Block your flag provider's domain in staging and see what happens. Does your app crash? Return defaults? Keep working normally?
Understand your SDK's caching
How long does it cache configurations? What happens when the cache expires and the provider is unreachable?
Have a manual override plan
Can you hardcode flag values in an environment variable or config file as a last resort? Document the process before you need it.
Monitor flag evaluation latency
If your flag checks suddenly take 500ms instead of 1ms, something's wrong upstream. Catch it before your users do.
Consider local-first evaluation
If your current provider evaluates flags server-side, understand the resilience implications and plan accordingly.
The real cost of flag provider downtime
Say you're an e-commerce company doing $10M/year in revenue. That's roughly $1,140 per hour. If a feature flag outage prevents you from killing a broken checkout flow for even 2 hours, you're looking at real revenue loss — not to mention customer trust.
And the indirect costs are worse: engineering time spent on incident response instead of building product, lost confidence in your deployment process, and compliance risk if you can't demonstrate control over feature rollouts during audits.
The irony? You adopted feature flags to reduce deployment risk. If your flag provider introduces new risk, something's wrong.
The bottom line
Feature flags are infrastructure. Treat them that way.
The February 2026 LaunchDarkly outages weren't catastrophic. Most customers were fine. But they were a reminder that any cloud service can go down, and when that service controls your feature rollouts, you need a plan.
Build for resilience. Evaluate locally. Have fallbacks. And if you're paying $10/seat/month for the privilege of worrying about someone else's uptime, maybe it's time to look at alternatives.