• Why should I avoid individually targeting too many users?

    Individually targeting users increases the size of the payload fetched by the SDK when initializing, and the memory footprint of the SDK.

    A better strategy would be to assign a custom attribute to the users who should receive the feature flag and then set up the targeting rules to serve the flag to users who have that attribute. This allows you to target groups of users without increasing the size of the payload.

    Read more about our targeting rules. 

  • How can I be notified of interruptions to the LaunchDarkly service?

    The best way to get updates from us regarding service status is by subscribing to this RSS feed:

  • The difference between SP- and IdP-Initiated SSO?

    LaunchDarkly supports only IdP-initiated SSO:

    Identity Provider Initiated (IdP-initiated) SSO.  With this option, your end users must log into your Identity Provider's SSO page (e.g., Okta, OneLogin, or Microsoft Azure AD) and then click an icon to log into and open LaunchDarkly the web application. 

    Service Provider Initiated (SP-initiated) SSO.  LaunchDarkly does not support this option: This option gives your end users the ability to sign into the apps Login page and then sends an authorization request to the Identify Provider (e.g., Okta, OneLogin, or Microsoft Azure AD). Once the IdP authenticates the user's identify, the user is logged into app. 

  • MFA Verification Failed. Code is Invalid

    You may see an error indicating your MFA code is invalid. This error is caused when the 6 digit code generated by your authenticator app has expired or is tied to the wrong QR code. 

    If you're trying to set up MFA for the first time, or re-enable MFA after a reset, one possibility is that you're using a 6 digit code from your authenticator app that is tied to a different QR code than the one displayed on the current page. If you're setting up MFA by scanning a new QR code, be sure not to refresh the page before entering your 6 digit code, or a new QR code will be generated, rendering the code on your applicator obsolete. If you're signing up for a new account, or setting up MFA for the first time, we recommend taking the following steps to ensure you're working with the correct QR code:

    1. Delete all existing LaunchDarkly QR codes in your authenticator app.
    2. Follow the invitation link from your email and scan the QR code displayed.
    3. Immediately enter the 6 digit code generated from your application without refreshing.

    If you have confirmed that your 6 digit code is being generated for the correct application, or you have already successfully enabled MFA and you are seeing this error, this may be caused by the clock on your authenticator app being out of sync. We recommend the Google Authenticator app, and Google recommends the following steps to verify that you have the correct time on your authenticator app:

    1. Go to the main menu on the Google Authenticator app
    2. Tap More  Settings.
    3. Tap Time correction for codes
    4. Tap Sync now

    If you're still experiencing any issues, please contact

  • How long does it take for users to appear in the dashboard?

    It generally takes just a couple of minutes for a user to appear in the dashboard. 

    You can check the debugger to verify that the users data is being sent to LaunchDarkly. If you open the debugger in an active tab and call variations on your users, you will see them appear in the debugger almost immediately. This is a great option to make sure that LaunchDarkly is receiving your user data without waiting for users to appear in the dashboard.

    You can read more about the debugger in our documentation here.

  • I am unable to connect because of a mismatched origin header
    We take the security of your data at LaunchDarkly seriously. One of the protections we've implemented is validation that the Origin header for any API request authenticated by session cookie matches the expected Origin header (namely This is just one way that we help to prevent CSRF attacks. (Note that we do not require origin matching when authenticating via Access Token, so this does not affect normal API usage.)
    If the Origin header does not match what's expected, we return an error. And since our application relies heavily on interaction with the API, the application will not function properly.
    Known causes
    Any browser extension that intentionally changes the Origin header will cause this problem. For example, the Allow-Control-Allow-Origin: * Chrome extension is known to change the Origin header to and will result in the problems described above.
See all 11 articles


  • Rules targeting users by attribute are not working

    Everything works as expected when you target users individually, and users appear to be receiving the correct variation based on the default rule. So why aren't your rules targeting users by attribute working as expected?

    The SDK will only evaluate flags using the user object you provide it. The SDK does not use the attributes shown on the dashboard, and user attributes are not synchronized across SDK instances. The only information that is synchronized is flag configuration related data. You will need to provide all applicable user attributes for your configured targeting rules to apply.

  • Java SDK: How do I use the SDK behind a HTTP/HTTPS proxy?

    The following example shows how to configure your SDK to connect to LaunchDarkly through a HTTP/HTTPS proxy.

    LDConfig config = new LDConfig.Builder()
        .proxyUsername("USERNAME") // OPTIONAL
        .proxyPassword("PASSWORD") // OPTIONAL
    .build(); LDClient ldClient = new LDClient("YOUR_SDK_KEY", config);


  • JavaScript SDK: Events blocked by DNT or Adblock

    When you evaluate feature flags, the SDK queues up an analytic event to send back to LaunchDarkly. The events endpoint is used to send these events. If you are working with the JavaScript SDK, enabling your browser's Do Not Track setting or using Adblock will block all requests to 

    Rest assured that this does not impact your user evaluations - your users will continue to receive the correct variation for the requested flags. This only impacts the ability to send information back to LaunchDarkly.

  • Does the LD SDK support using Postgres to cache feature flag configurations?

    Not currently, though we have a store abstraction that you can extend with your own storage backend like Postgres. You can read more about what caches we support here:

  • I am getting a JSON parsing exception with the Java client


    Json parsing exception: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was….ExceptionType:

    Make sure your build tool is bringing in the proper version of Gson. The LaunchDarkly SDK may have problems with versions earlier than 2.2.4. To enforce the proper version add this dependency:



  • I am getting SSL exceptions when calling variation() in the Java client

    Make sure your build tool is bringing in the proper version of the Apache http client. The LaunchDarkly SDK may have problems with versions earlier than 3.3.6. To enforce the proper version add this dependency:

    1. <dependency>
    2.  <groupId>org.apache.httpcomponents</groupId>
    3.  <artifactId>httpclient</artifactId>
    4.  <version>4.3.6</version>
    5. </dependency>


  • How do the mobile SDKs handle airplane/flight mode?

    When a user is in flight or airplane mode on their mobile device, LaunchDarkly will use the latest stored flag settings.  When the user reconnects to a network, LaunchDarkly will reconnect to the stream to see if there are any new flag updates.  This ensures that your users will always receive the most up-to-date flag settings, even if their devices are not currently connected to a network.

  • I’m seeing inconsistencies in iOS SDK flag evaluation

    There are a few things to be aware of with the iOS SDK:

    • The iOS SDK utilizes a streaming architecture to keep itself in sync with your configurations on the dashboard. If any change is made, these changes will be picked up by your iOS users the next time they get online.
    • When the SDK receives any updates from LaunchDarkly they are cached to Core Data, so that the SDK can still evaluate flags even when offline.
    • When a user first installs your app, until the first stream is established with LD, the default variation values will be used. There is a delegate pattern (see userDidUpdate) that can be used to block until the first response is received.
    • When a current user uses the app while offline, or if variation calls are made before the SDK has has finished initializing, then the SDK will continue to serve variations using the old state, and you may see these events show up occasionally in your dev console after making changes.
    • If your SDK If you need to change your user, or you want to wait until the SDK has finished synchronizing with LaunchDarkly, you should use the userDidUpdate delegate to wait until the feature flags for the new user have been received.
  • Why is there a different mobile environment SDK key?

    The server SDK keys are intended to be embedded in trusted environments. The mobile SDK keys are suitable for use in (untrusted) mobile clients. If a mobile user were to somehow decompile your app, or gain access to your mobile key, there is really no impact, as those keys can only access a restricted subset of our APIs that do not reveal any private data.