Did the LaunchDarkly outage cause SDK crashes after restarts?

The restart could be the key. A running service may still have cached flag values, while a restarted instance has to fetch them again. If flag delivery is broken at that point, the restart can turn a partially contained outage into a startup problem.

That does not explain the exception on its own, though. Check whether the SDK had usable flag data before and after the restart, and look at the exception and initialization logs.

There were reports of unhandled SDK exceptions in a few instances even after restarts and an initial resolution announcement. So a restart was not necessarily a clean fix, and it is worth checking individual instances rather than assuming they all recovered together.

One way to limit the dependency is to keep some feature flags at the database level too, particularly when supporting self-hosted deployments. That gives you another place to control relevant behavior if the external flag service is unavailable.

The impact seems to have depended a lot on what relied on those flags. An invoicing system was reported to have failed during a busy end-of-period window, so even a short disruption could land at a particularly bad time for some teams.