• 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

  • 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 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 dev console to verify that the users data is being sent to LaunchDarkly. If you open the dev console in an active tab and call variations on your users, you will see them appear in the console 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.

  • 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:

  • 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.
  • What does "Your configuration is incomplete" mean?

    If you're seeing the "Your configuration is incomplete" message, it will usually indicate that there is an incomplete or invalid rule configured for your flag. For example, this could mean that an attribute was not selected, or a negative number was selected for a percentage rollout.

See all 10 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.

  • 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 Postgres as a caching backend?

    Not currently, though we have a store abstraction that you can extend with your own storage backend like Postgres.

  • 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>
  • Every time I call get_flag, a remote call is made.

    One possibility is that you have streaming mode disabled and your feature’s TTL is set to 0. We do not recommend disabling streaming unless you are using PHP. If you do disable streaming mode, we recommend setting the TTL to 5 minutes in production environments.

    If you’re using PHP, you may need to configure a custom HTTP cache provider as described in the PHP SDK Reference. PHP’s shared-nothing architecture means that the in-memory HTTP cache will be reset on every request, which means that almost every flag request will require a remote call. Using a Memcache or Redis-backed cache is the best solution.



  • 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.