New to Kestra?
Use blueprints to kickstart your first workflows.
Audits LaunchDarkly feature flag evaluation volumes, detects unexpected client request spikes, and alerts platform teams via Slack.
Modern software delivery practices rely on LaunchDarkly feature management to perform progressive rollouts, dark launches, and automated kill-switch operations across web, mobile, and backend microservices. However, temporary feature flags frequently linger in application codebases months after rollouts reach 100% completion. Over time, accumulated dead toggle branches inflate client SDK initialization payloads, waste memory, and increase code branching complexity. Furthermore, if client applications enter unexpected rendering loops or unthrottled polling routines, evaluation request volumes spike abruptly, degrading local SDK cache efficiency and increasing consumption costs. This sentinel interrogates the LaunchDarkly REST API v2 on an hourly schedule, validates flag lifecycle statuses and archive states, and alerts engineering teams on Slack with direct console links to retire obsolete feature toggles.
0 * * * *) or runs on-demand via manual execution./api/v2/flags/{project}/{flag} to inspect the flag definition, friendly name, and archival status./api/v2/flag-statuses/{project}/{environment}/{flag} to retrieve evaluation activity states across environments.io.kestra.plugin.core.flow.If flowable checks if lifecycle anomalies are detected and dispatches a Slack alert to #feature-flags.flowchart TD
A[hourly_launchdarkly_audit Schedule Trigger] --> B[evaluate_flag_status Python Script]
B --> C[check_flag_anomaly Flowable If]
C -- Anomaly or Debt Detected --> D[notify_slack_flag_alert Webhook]
C -- Configuration Nominal --> E[log_flag_status Log]
D --> E
E --> F[export_flag_manifest Return]
Feature flags often linger in code long after rollouts conclude because developers move on to new initiatives without cleaning up toggle logic. Kestra provides an automated governance loop that periodically inspects flag statuses via LaunchDarkly APIs, identifies obsolete toggles, and notifies product teams to prune dead branches. With Kestra's containerized Python runner and native secret management, teams automate feature toggle governance without building custom cron daemons.
| Name | Type | Default | Description |
|---|---|---|---|
project_key |
STRING |
default |
Key identifier of the target LaunchDarkly project. |
environment_key |
STRING |
production |
Key identifier of the target LaunchDarkly environment. |
flag_key |
STRING |
new-checkout-pipeline |
Feature flag key to audit for evaluation status and lifecycle debt. |
alert_on_anomaly |
BOOL |
true |
Whether to dispatch automated Slack alerts when archived or stale feature flags are detected. |
{{ outputs.evaluate_flag_status.vars.flag_name }}: Human-readable display name of the evaluated feature flag.{{ outputs.evaluate_flag_status.vars.status_name }}: Current operational status of the flag in the target environment.{{ outputs.evaluate_flag_status.vars.has_anomaly }}: Boolean flag indicating whether lifecycle anomalies or debt were detected.{{ outputs.export_flag_manifest.value }}: Structured dictionary containing the consolidated flag audit summary.app.launchdarkly.com.Reader or Writer permissions.LAUNCHDARKLY_API_KEY: LaunchDarkly API access token with permissions to read project flags and statuses.SLACK_WEBHOOK_URL: Slack Incoming Webhook URL used to dispatch feature flag governance alerts.LAUNCHDARKLY_API_KEY and SLACK_WEBHOOK_URL in your Kestra secret storage.company.operations namespace.project_key, environment_key, and flag_key with your target toggle details.Bearer prefix; ensure your token is passed directly in the header.LD-API-Version: beta header to access real-time status data.project_key and environment_key correspond to exact URL keys rather than human-readable display names.io.kestra.plugin.core.flow.ForEach loop to scan all flags across the project.