Script icon
Docker icon
If icon
SlackIncomingWebhook icon
Log icon
Return icon
Schedule icon

LaunchDarkly Flag Evaluation Request Spike Sentinel

Audits LaunchDarkly feature flag evaluation volumes, detects unexpected client request spikes, and alerts platform teams via Slack.

Categories
CloudInfrastructure

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.

How it works

  1. Scheduled triggering: Executes every hour via automated cron trigger (0 * * * *) or runs on-demand via manual execution.
  2. Flag configuration query: Calls /api/v2/flags/{project}/{flag} to inspect the flag definition, friendly name, and archival status.
  3. Environment status evaluation: Queries /api/v2/flag-statuses/{project}/{environment}/{flag} to retrieve evaluation activity states across environments.
  4. Lifecycle debt comparison: Identifies flags marked as temporary that have transitioned to inactive or completed states, or archived flags still queried by clients.
  5. Conditional alerting: An io.kestra.plugin.core.flow.If flowable checks if lifecycle anomalies are detected and dispatches a Slack alert to #feature-flags.
  6. Manifest export: Emits a structured JSON audit payload detailing flag metadata and status for technical debt burndown tracking.

Architecture diagram

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]

What you get

  • Continuous detection of archived flags still queried in production codebases.
  • Proactive discovery of stale temporary flags exceeding enterprise lifecycle guidelines.
  • Actionable Slack notifications containing direct permalinks to the LaunchDarkly management console.
  • Structured JSON audit manifests supporting engineering technical debt burndown reviews.

Who it's for

  • Release Engineers managing progressive delivery and canary feature releases.
  • Platform Engineers guarding against client-side evaluation storms and SDK overhead.
  • Software Architects maintaining clean codebases and retiring deprecated feature toggles.

Why orchestrate this with Kestra

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.

Use cases

  • Feature Flag Technical Debt Burndown: Identify temporary release flags that have remained unchanged for over 60 days and notify authors.
  • Archived Flag Evaluation Warning: Detect when archived flags receive evaluation calls from legacy mobile app versions.
  • Multi-Environment Drift Verification: Ensure flags enabled in staging environments are consistently promoted or cleaned up across production.

Inputs

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.

Expected outputs

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

Prerequisites

  • Outbound HTTPS network access from Kestra execution workers to app.launchdarkly.com.
  • A LaunchDarkly API access token with Reader or Writer permissions.
  • A Slack Incoming Webhook URL configured in Kestra secrets.

Secrets

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

Quick start

  1. Register LAUNCHDARKLY_API_KEY and SLACK_WEBHOOK_URL in your Kestra secret storage.
  2. Import this blueprint into your Kestra instance under the company.operations namespace.
  3. Update project_key, environment_key, and flag_key with your target toggle details.
  4. Run a manual execution to verify LaunchDarkly API connectivity and validate the output manifest.

Common pitfalls and troubleshooting

  • API Token Header: LaunchDarkly uses direct token authorization without a Bearer prefix; ensure your token is passed directly in the header.
  • Beta API Version: Flag status endpoints require the LD-API-Version: beta header to access real-time status data.
  • Project vs Environment Keys: Ensure project_key and environment_key correspond to exact URL keys rather than human-readable display names.

How to extend

  • Automated Pull Request for Flag Cleanup: Trigger a downstream workflow to search the codebase for the flag key and open a GitHub PR removing the dead code.
  • Jira Technical Debt Issue Creation: Automatically create a Jira ticket assigned to the flag maintainer when a toggle exceeds 90 days.
  • Bulk Flag Audit Loop: Wrap the evaluation in an io.kestra.plugin.core.flow.ForEach loop to scan all flags across the project.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.