Introduction
Understanding organizationsUnderstanding componentsManage organizationsManage componentsManage component Jira integrations
Set up your first organizationUnderstanding users and teamsUnderstanding role-based access controlManage usersManage teamsConfigure role-based access controlRBAC permissions reference
Understanding authentication in CloudBees UnifySet up multifactor authenticationConfigure SAML single sign-onConfigure OIDC authenticationConfigure network security policiesNetwork security reference
Understanding platform configurationUnderstanding environmentsManage properties and secretsManage environmentsTrack environment inventoryConfigure containersSet up preconfigured actionsConfigure notifications
Accessibility policy referenceShared responsibility model referenceSubscription and services agreementSupport policiesSupported browsers and external tools
Introduction
Understanding feature managementUnderstanding Configuration as CodeGet started with feature managementCreate and manage feature flagsConfigure feature flag targetingOrganize feature flagsImplement feature flag governanceConfiguration as Code reference
Understanding flag impressions and activity statusUnderstanding flag healthUnderstanding code referencesReview and clean up feature flagsSet up code references
Understanding Jira integration for feature flagsSet up the Jira integrationLink Jira tickets to feature flags
Understanding multiple SDK keysBuild your first mobile app with feature flagsBuild your first feature-flagged web applicationBuild your first feature-flagged backend serviceInstall client-side SDKsInstall server-side SDKsConfigure multiple SDK keysMobile SDK referenceWeb SDK referenceBackend SDK referenceClient SDK referenceFlag implementation reference
Introduction
Understanding CI workflowsCreate a build workflowCreate and manage workflowsCreate reusable workflowsTest and validate containers in workflowsCheck out source codeTrigger workflows remotelyWorkflow syntax referenceJobs syntax referenceSteps syntax referenceServices syntax reference
Monitor workflow runsView test results in runsView evidence in runsView deployments in runsManage workflow artifactsPublish test resultsPublish evidence itemsGenerate a software bill of materialsManage ServiceNow change requests
Configure workflow credentialsConfigure AWS credentialsConfigure container registry credentialsConfigure Git credentialsIntegrate external secret providers
Understanding GitHub Actions integrationSet up GitHub Actions integrationDisplay GitHub Actions workflows and runsRegister GHA build artifactsPublish GHA deployed artifactsPublish GHA test resultsPublish GHA evidence itemsTrigger CloudBees workflows from GitHub ActionsScan with GitHub Actions
Understanding CloudBees CI and Jenkins® integrationConnect CI and Jenkins controllersMonitor CI and Jenkins buildsRegister CI build artifactsRegister CI deployed artifactsPublish CI test resultsConfigure CI security scanningCI and Jenkins integration reference
Build and publish container imagesUnderstanding external CI/CD integrationsRun external CI/CD jobsExternal CI/CD action reference
Introduction
Understanding release orchestrationManage applicationsCreate deployer workflowsCreate staged workflowsCreate and manage releasesOrchestrate multi-workflow releasesRelease management reference
Understanding artifact managementRegister and track artifactsStore and retrieve artifactsPromote artifactsGenerate a software bill of materialsArtifact management reference
Deploy with HelmDeploy to KubernetesContainer deployment reference
Deploy to AWSAWS deployment reference
Deploy with enterprise platformsExecute remote deployment commandsEnterprise deployment reference
Verify deployments with New RelicDeployment verification reference

Understanding flag health

3 minute read

Flag health reflects how effectively flags are maintained across environments: whether they are active, influencing behavior, or accumulating as technical debt. This page explains what signals make up flag health, how lifecycle statuses are derived, and what stale flags represent.

What flag health measures

Flag health is not a single metric but a composite view combining impression data, configuration consistency across environments, and lifecycle status. Over time, feature flags that are no longer serving their purpose tend to accumulate in configuration. These stale flags increase code complexity, obscure what is actually live, and introduce risk when teams make changes without understanding which flags are still in play. The health view surfaces this proactively, so flag cleanup becomes an ongoing practice rather than a periodic manual audit.

The signals that make up flag health

Four sources feed the health view:

Flag impressions record how often a flag is evaluated and what values it returns. Impression data is the primary input for determining whether a flag is active, settling, or dormant.

Activity status is derived from impression patterns and describes where a flag sits in its lifecycle. Refer to Flag lifecycle statuses for the full set of statuses.

Environment comparison identifies whether a flag is configured consistently across environments. A flag can be active in production but stale in staging; the health view surfaces both states simultaneously, making cross-environment inconsistency visible.

Cleanup candidates are flags that CloudBees Unify has identified as stale or inactive and surfaced for review in the flags overview. This is not automatic deletion but a mechanism for drawing attention to flags that warrant a closer look.

Flag lifecycle statuses

CloudBees Unify derives a lifecycle status for each flag from its impression data. For detail on how each status is calculated, refer to Understanding flag impressions and activity status.

Status Description

Setup

The flag exists in CloudBees Unify and may include configuration, but has not yet received any impressions. This is the typical status immediately after a flag is created.

Active

The flag has received impressions returning different values during the selected timeframe.

Stale

The flag has received impressions during the selected timeframe, but all with the same value. The flag is no longer affecting behavior.

Inactive

The flag has received no impressions during the selected timeframe and may no longer be in use.

Permanent

A user-defined status that excludes the flag from impression tracking and lifecycle calculations. Intended for long-lived flags with no retirement plan.

What stale flags represent

The distinction between stale and inactive is worth understanding, because the two statuses point to different situations.

A stale flag has been evaluated recently, but consistently returns the same value. It is still in the SDK evaluation path, but it is no longer affecting behavior. The rollout it controlled has effectively completed. Stale flags are the most common cleanup candidate: the feature shipped, the flag was never removed, and it is now just noise in the configuration.

An inactive flag has received no impressions in the selected timeframe. This can mean the SDK call has been removed from the codebase, the application is not running in the selected environment, or the flag was created but never implemented. Each of these scenarios calls for a different response, which is why inactive flags warrant review rather than automatic removal.

Cleanup candidates

CloudBees Unify surfaces stale and inactive flags as cleanup candidates in the flags overview. The cleanup candidates summary shows the count of stale flags against the total, and toggling the view filters the list to show only those flags.

Cleanup candidates are a starting point for review, not a deletion queue. Before removing a flag, you should check its code references to confirm it is no longer referenced in the codebase, and verify it has no active dependencies. Flags marked as permanent are excluded from cleanup candidate identification entirely.

For the step-by-step cleanup process, refer to Review and clean up feature flags.

Understanding flag impressions and activity status
Understanding code references