This topic explains how to use health checks for guarded rollouts to confirm your rollout setup and troubleshoot configuration problems.
All LaunchDarkly accounts include a limited trial of guarded rollouts. Use this to evaluate the feature in real-world releases.
Health checks help you confirm that your flag or AgentControl config, metrics, and context configuration allow Release Guardian to measure rollout performance correctly.
When you create a guarded rollout, LaunchDarkly displays a health check status below the Target by field.
The possible statuses include:
Hover over the status to view detailed health checks.
The individual health checks are described below.
This health check confirms that LaunchDarkly receives evaluation data for the flag or AgentControl config.
Possible statuses include:
To review evaluation traffic, expand the Evaluations graph at the top of the Targeting tab.
Your organization creates a guarded rollout using the user context kind. After saving, the health check displays Flag is not receiving evaluations. This means LaunchDarkly has not received evaluation data for the flag.
To resolve this issue:
After LaunchDarkly receives evaluations, the health check updates to Flag is receiving evaluations.
This health check confirms that evaluations use the same context kind as the rollout’s randomization unit.
If the flag evaluates against a different context kind than the one selected in the Target by menu, Release Guardian cannot measure rollout performance.
Possible statuses include:
To learn more, read Randomization unit and Context kinds.
A guarded rollout uses organization as the randomization unit. The health check displays Flag is not seeing organization. Evaluations reaching LaunchDarkly do not include the organization context kind.
Your developers discover that the frontend sends a multi-context with both user and organization, while the backend sends only user. Because the rollout uses organization as the randomization unit, Release Guardian cannot measure performance until evaluations include organization.
To resolve this issue:
user and organization.organization context kind is marked as Available for experiments and guarded rollouts.When evaluations include the required context kind, the health check updates to Flag is seeing organization.
This health check confirms that each selected metric uses the same randomization unit as the guarded rollout.
The metric randomization unit health check appears only after LaunchDarkly receives events for the metric.
Possible statuses include:
Randomization units depend on how the metric is configured, not on the event data currently sent to LaunchDarkly.
Your organization creates a guarded rollout and selects request as the randomization unit. Two latency metrics are attached. One metric uses request. The other uses user. The health check displays request is not tracked by latency percentile.
To resolve this issue:
After metric events match the selected randomization unit, the health check updates to request is tracked by latency percentile.
This health check confirms that LaunchDarkly receives recent metric events.
Possible statuses include:
If metrics do not send events during a period of time, difference charts display a flat segment using the most recent value. This approach keeps the timeline continuous and ensures hover behavior remains smooth.
You can confirm metric activity by reviewing the metric’s Activity tab.
A guarded rollout includes a conversion metric named Checkout conversions. The health check displays No recently seen events for Checkout conversions. The metric’s Activity tab shows that it last received events 90 days ago. The checkout flow changed, and the SDK no longer sends the checkoutCompleted event that the metric expects.
To resolve this issue:
checkoutCompleted event is sent again.After events resume, the health check updates to Recently seen events for Checkout conversions.