LaunchDarkly does not support automatic provisioning of new team member accounts. If new team members attempt to log in for the first time via the LaunchDarkly website, they will get an "invalid e-mail or password" error. They will not be automatically routed to login via your Identity Provider.

To add new team members, they must access a LaunchDarkly application set up in your Identity Provider to initiate the first login to LaunchDarkly in order for the account to be created. Once that step has been taken, they will be redirected when attempting to log in via the LaunchDarkly website. 

Read more about user provisioning in our documentation here.

If a team member has multiple custom roles, we iterate through each role and see if it will approve the action. If so, the action is approved immediately. If the role denies a certain action, we continue to iterate through the remaining roles to see if any of those roles approve that action. 

In short, if a user has a custom role that allows an action that another custom role denies, the action will ultimately be allowed.

If MFA is enabled and you are locked out of your LaunchDarkly account, you can contact the LaunchDarkly owner or one of the admins at your company to get a reset code. Once you receive this reset code, you will need to head to your profile settings page and re-enable MFA using an authenticator app on your phone.

Are you the account owner? Unfortunately, no one at your organization has sufficient permissions to reset your MFA. Reach out to support@launchdarkly.com and we can help you regain access to your account. 

We're sorry to see you go. To cancel your subscription, you can contact your Account Executive or email support@launchdarkly.com. 

If you are looking to delete a trial account that has no subscription, you may wish to reference the following knowledgebase article here.

We have a 30 day grace period to allow for plenty of time to sort out any payment failures. In the event this grace period expires, we would have a conversation with you. You never need to worry about an unexpected interruption of your service. 

Your users will continue to receive the correct variations for their flags. The only impact is that once your payment is more than 30 days late, you will hit a paywall when trying to log into your LaunchDarkly account.

Contact support@launchdarkly.com if you have any concerns or require any additional support or information regarding a payment failure. 

Please have the current owner email support@launchdarkly.com to request the change of ownership. The owner role is the only role that is unable to be changed by an admin of your LaunchDarkly team. Include the email of the team member who you would like to designate as the new owner and we will set this team member as the new owner, and give the former owner admin privileges. 

Support may need to reply before making the change to confirm this request is coming from you. It's easiest to verify your identity if the owner submits the request while they are logged in to their LaunchDarkly account.

All other roles aside from the owner can be changed from the team tab. The owner or any admins can navigate to this page and hit the "edit" button next to the team member whose role you would like to change. 

Check out our Getting Started Checklist to get the most out of LaunchDarkly.

After you create a LaunchDarkly account, you will have access to our Quickstart.  The Quickstart will walk you through the creation of your first feature flag using any of our SDKs.  You can use our Hello World sample app or create a sample feature flag in your own test environment.

LaunchDarkly is a continuous delivery and feature flag management platform built for teams. The platform allows companies to continuously deliver and deploy software to their users in a faster, more reliable way. You wrap your features in LaunchDarkly flags, which allows you to have full control over who sees the feature (users or user groups). It helps companies perform gradual feature rollouts, disable buggy features without redeploying, and reduce development costs with a more streamlined development cycle.

Feature flags are a software development best practice of gating functionality. Functionality can be deployed “off”, then turned on via the feature flag, separate from deployment. With feature flags, you can manage the entire lifecycle of a feature.

LaunchDarkly revolutionizes software development by allowing you to iterate quickly and safely. We allow you to easily flag your features, which enables you to manage them from the LaunchDarkly dashboard.

• Roll out a new feature to a subset of your users (like a group of users who opt-in to a beta tester group), gathering feedback and bug reports from real-world use cases.
• Gradually roll out a feature to an increasing percentage of users, and track the effect that the feature has on key metrics (for instance, how likely is a user to complete a purchase if they have feature A versus feature B?).
• Turn off a feature that you realize is causing performance problems in production, without needing to re-deploy, or even restart the application with a changed configuration file.
• Grant access to certain features based on user attributes, like payment plan (eg: users on the ‘gold’ plan get access to more features than users in the ‘silver’ plan). Disable parts of your application to facilitate maintenance, without taking everything offline.

Yes! We’ve made LaunchDarkly extremely developer-friendly and easy to integrate. You and your team can start controlling your first feature in minutes. We also provide excellent customer support to help you get started.

See our getting started guide.

Our unique streaming architecture ensures that feature flags are updated instantly, without introducing any latency to your site. LaunchDarkly’s performance is even faster than storing feature flags in your own database. We also have multiple layers of redundancy. All flags are served locally and are backed up by two layers of globally distributed CDNs. With the architecture, a feature flag will always be available.

Complete this form to schedule a free demo and we will be happy to demonstrate the platform and answer all your questions. Our feature flag platform is built to support both small and large development teams with enterprise-grade speed and reliability.

We calculate the number of unique users across all environments over your billing cycle. Anonymous users are tracked by session, so a single user who visits multiple times will only be counted once.

Our targeting rules evaluate from top to bottom and take the first match. The first matching rule will take precedence over any of the rules that follow.

Learn more about this in our documentation here.

LaunchDarkly lets developers wrap features or application behavior in our feature flags. You can then manage your features on the LaunchDarkly dashboard, roll out to users, and see how well things are performing. LaunchDarkly gives you total control of your application.

• Turn features on and off for your users without waiting for engineering.
• Roll out to percentages of your population, segments, or whatever rules you define.
• Get faster feedback from the people you want. Measure the impact of your features with our NewRelic and Optimizely integrations.
• Create custom rules for granular targeting
• Manage configurations using our multivariate feature flags

LaunchDarkly supports both boolean and multivariate feature flags. A boolean flag has two variations true and false, which works best for feature flags that will simply turn things on and off. A multivariate flag allows you to define two or more custom variations. These variations can be strings, numbers, JSON objects, or JSON arrays. Check out the docs.

LaunchDarkly supports the following SAML 2.0 identity providers:

• Okta
• OneLogin
• Azure Active Directory
• Google Apps
• Active Directory Federation Services (ADFS)
• PingIdentity
• Centrify

See our documentation for complete setup instructions as well as configuration tips for specific providers.

LaunchDarkly targeting lets you turn features on or off for individual users or groups of users. You can use the Targeting tab to roll features out for internal testing, private betas, or usability tests before performing a broader rollout. You can create your own rules to target who you want, when you want.

Learn more about targeting users in our documentation here.

In addition to targeting individual users, LaunchDarkly allows you to target segments of users by constructing custom rules.In other words, you can create custom rules to target users based on any attributes you send us.

Each rule has three parts: an attribute, an operator, and a user value.   You can create as many custom targeting rules as you want for each feature flag and even perform percentage rollouts for each rule.

All users that have not been individually targeted or who are not targeted by a custom rule will be evaluated by the default rule.

Learn more

LaunchDarkly provides you with a centralized dashboard to manage the lifecycle of your features from local development, to QA, to production. Manage multiple different software projects with their own development environments.

Projects allow you to manage multiple different software projects under one LaunchDarkly account. For example, you can create one project called Mobile App and another project called Web App. Each project will have its own unique set of environments and feature flags. By default, all team members in your LaunchDarkly account will have access to every project within that account.

Environments allow you to manage your feature flags throughout your entire development lifecycle — from local development to QA, staging, and production.

When you first sign up, you're provided with two environments within a project. By default, they're named Test and Production. Each environment has its own private SDK key, which is used to connect a LaunchDarkly SDK to a specific environment.

Each feature flag that you create has its own unique set of targeting rules for each environment. This means that you can change your flag rollout rules in a development or staging environment for QA testing before rolling out to production.

Anonymous users work just like regular users, except these users are not stored in your dashboard. One of the primary reasons that users are sent anonymously is to avoid having a lot of unauthenticated users polluting the user dashboard. Another reason is to avoid sending PII, but we recommend the use of private user attributes if that is the case. 

There are some cases where you do need to generate a unique key for anonymous users. If you are targeting users individually by key, using LaunchDarkly's A/B testing feature, or the Analytics Data Stream you would want unique keys. You also want unique keys when conducting percentage rollouts. For that reason, the general documented advice is to treat the anonymous users like regular users and assign unique IDs. 

If you do not have a need to uniquely identify your anonymous users, you could use a shared key for these users.

When a conversion event comes in, we try to find the 'closest' feature event. To do this, we look for the latest feature event for this user in the 24 hours preceding the conversion event. (Failing that, we will look for the earliest feature event for that user in the 5 minutes following the conversion event, to allow for clock skew). Once we find a feature event, we look at which variation that user saw, and we add the user to the set of users who saw that variation and converted.

So, suppose the following timeline:

t0: user X sees variation A
t1: user X sees variation B
t2: user X triggers a conversion event

As long as there is less than 24 hours between t2 and t1, user X will be added to the variation B conversion set (and *not* the variation A conversion set).

In this same timeline, but when there is more than 24 hours between t2 and t1, we will not find a feature event, so the conversion will not count at all.

Suppose an alternate timeline:

t0: user Y sees variation A
t1: user Y triggers a conversion event
t2: user Y sees variation B
t3: user Y triggers a conversion event

If there is less than 24 hours between t1 and t0 AND less than 24 hours between t3 and t2, then user Y will be counted in both the variation A conversion set *and* the variation B conversion set. 

Now, suppose a third timeline:

t0: user Z sees variation A
t1: user Z triggers a conversion event
t2: user Z sees variation A
t3: user Z triggers a conversion event

If there is less than 24 hours between t1 and t0 AND less than 24 hours between t3 and t2, then user Z will be counted *once* in the variation A conversion set.

Keep in mind that the important time limit here is 24 hours. If someone converts 5 days (or 2 days) after (or 2 days) getting a variation, they will not be counted.

Contact us at support@launchdarkly.com if you have any additional questions.

LaunchDarkly lets you create goals to measure the effectiveness of a feature. You can track click goals, page view goals, or create custom goals. We also provide an Optimizely integration so you can import your existing goals. We track all user events and let you see exactly how a feature is performing. Our analytics dashboard will help you see which feature variations are performing the best.

Read more

The SDK relies on its stored state to evaluates flags. By default the SDK first initializes with an empty state. When the SDK first initializes, it opens a streaming connection to LaunchDarkly. The initial response from LaunchDarkly contains the SDKs current state. The SDK will then keep this streaming connection open and when any change is made in the LaunchDarkly dashboard or via the Rest API, LaunchDarkly will send these changes to all currently connected SDKs.

If the SDK ever loses connectivity to LaunchDarkly then it will continue attempting to establish a streaming connection until it succeeds. If you try to evaluate a flag before the SDK receives its initial state, or you try to fetch a flag which otherwise doesn't exist, then the SDK will return the fallback value. All SDKs provide synchronous (through blocking and/or polling) and asynchronous ways of waiting for the SDKs state to initialize.

In most cases no— our streaming connection only requires that your server be able to make an outbound HTTPS connection to *.launchdarkly.com.

Almost nothing. LaunchDarkly’s SDKs use a streaming connection to asynchronously receive updates to your feature flag rules. Your actual feature flag requests are served from memory (or a Redis store, if you configure one). This adds less than 1 millisecond of latency to your page loads— about as fast as looking up a value in a hash table.

The variation a user receives is determined based on the users key. When a percentage rollout is evaluated it generates a hash from the user's key, the user's secondary attribute if available, and a hidden salt attribute stored in the flag. The SDK then uses this hash to generate a percentage which is used in conjunction with the percentage rollout configuration to determine the variation a user receives.

Yes, anonymous users are included in A/B testing. You will need to set an appropriate user key for anonymous users so that we can track each anonymous user separately; a session key might be appropriate. We don't display anonymous users on the Users screen because anonymous users couldn't be managed from LaunchDarkly, so they would only add clutter to the screen.

We do not impose a hard cap on MAUs. We'll never halt access or send you a weird bill based on overages. We allow for variance as we know a company's user base can grow unexpectedly over time. That said, we do limit the amount of users that will be saved in your dashboard. 

When you exceed your MAU, your new users and changes to existing users (such as new attributes) will no longer appear in the dashboard. It's important to note that your users will continue to evaluate their flags correctly. This only impacts your ability to view user updates in the dashboard.

All of our SDKs are built on top of the LaunchDarkly REST API. In fact, the entire LaunchDarkly web site is driven via the same API, so it’s heavily tested and complete. If you want to build a custom integration or export your data this API reference is the place to start.

You don’t have to send users to LaunchDarkly in advance – just set up your users in variation calls and you’re all set: http://docs.launchdarkly.com/docs/getting-started .

If we do not receive a request for a user in 30 days, then that user will no longer appear in the dashboard, but will still be stored in the database.   If we detect that the user is active again, then they will reappear in the dashboard with the latest set of attributes.  You cannot remove users manually from the dashboard.

You may add individual users using the LaunchDarkly dashboard by navigating to a feature flag and adding users manually in the targeting tab.

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. 

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.

The best way to get updates from us regarding service status is by subscribing to this RSS feed: http://status.launchdarkly.com/

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.

Make sure that you’re sending distinct user keys for each user in your variation calls. A few other possibilities:

• Your default rollout rule is serving a single variation
• Your users are receiving the fallback variation because something is not working correctly
• The kill switch was activated, and the feature is set to ‘Off’

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.

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 events.launchdarkly.com. 

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.

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

Exception:

Json parsing exception: java.lang.IllegalStateException: Expected BEGIN_OBJECT but was….ExceptionType: com.google.gson.JsonSyntaxException

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:

<dependency>
 <groupId>com.google.code.gson</groupId>
 <artifactId>gson</artifactId>
 <version>2.2.4</version>
</dependency>

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:

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.