PostHog Feature Flag Safety Compliance Sentinel

A feature flag used as a kill switch or a staged rollout gate is only as safe as its current value, and PostHog has no native alert for "this flag is not what it should be right now". A flag flipped on by mistake, or a rollout that silently regressed, sits there until someone happens to check. This blueprint evaluates one flag for a representative user and compares it against the value you declare safe.

This blueprint was created by Mohit Jeswani.

How it works

1. check_flag (io.kestra.plugin.posthog.EvaluateFeatureFlag) asks PostHog for flag_key's value for distinct_id. allowFailure: true covers an API or host error without failing the flow outright.
2. evaluate (io.kestra.plugin.core.output.OutputValues) compares the flag's enabled value against expected_enabled. A failed evaluation (no output at all) is CRITICAL; a mismatch is DRIFT; a match is OK.
3. route (io.kestra.plugin.core.flow.If):
   • compliant: logs that the flag matches the expected state.
   • alert: posts the actual value, variant, and expected value to Slack.
4. summary logs the actual value and severity, closing the governance cycle.
5. errors alerts Slack if the flow itself fails, for example an invalid API key.

What you get

• A direct answer to "is this safety flag still in the state it should be", not a guess from the PostHog dashboard's current filter.
• Drift distinguished from an outright evaluation failure, so a flag that stopped resolving entirely reads as its own, different finding from a flag that flipped the wrong way.
• A record, in Kestra's execution history, of every check, not just the last time someone happened to look.

Who it's for

• Platform and SRE teams using PostHog feature flags as kill switches or staged rollouts who want drift caught automatically instead of discovered during an incident.
• Teams evaluating the PostHog plugin who want a worked example of EvaluateFeatureFlag used as a standing compliance check rather than a one-off lookup.

Why orchestrate this with Kestra

PostHog resolves the flag; it does not decide what value is safe, compare it against that expectation, or notify anyone when they diverge. Kestra keeps expected_enabled as a flow input instead of institutional memory, turns a flag check into a Slack page naming the actual value, and keeps a full execution history of every run.

Prerequisites

• A PostHog project (Cloud or self-hosted) with the feature flag already created and a project API key (phc_...).
• A representative distinct_id (a canary account, a synthetic test user, or a real user you are comfortable the flag evaluation targets) with a known expected flag state.
• A Slack incoming webhook URL.

PostHog is open source and self-hostable, unlike most plugins in this engagement: run docker run -d --name posthog -p 8000:8000 posthog/posthog:latest and point posthog_host at http://localhost:8000 (or http://posthog:8000 from inside the same Docker network) to validate this flow's logic end to end without a Cloud account.

Secrets

• POSTHOG_API_KEY: the PostHog project API key used by check_flag. In Kestra OSS, provide it as the base64-encoded environment variable SECRET_POSTHOG_API_KEY.
• SLACK_WEBHOOK_URL: used by alert and the errors block. In Kestra OSS, provide it as the base64-encoded environment variable SECRET_SLACK_WEBHOOK_URL.

Inputs

Input	Type	Default	Allowed values
posthog_host	STRING	https://us.i.posthog.com	Valid PostHog ingestion host URL
distinct_id	STRING	<canary-user-id>	Distinct user or canary account ID
flag_key	STRING	<your-flag-key>	PostHog feature flag key
expected_enabled	BOOL	false	true, false

Outputs

• {{ outputs.check_flag.value }}: raw evaluation value (boolean for boolean flag, variant string for multivariate, null if not returned).
• {{ outputs.check_flag.enabled }}: boolean indicating whether the flag evaluated as enabled.
• {{ outputs.check_flag.variant }}: variant name for multivariate flags (null if boolean or missing).
• {{ outputs.evaluate.values.actual_enabled }}: evaluated enabled status or unknown on probe failure.
• {{ outputs.evaluate.values.severity }}: compliance classification (OK, DRIFT, or CRITICAL).

Pitfalls

• Reading the flag sends a $feature_flag_called event to PostHog on every run, as the PostHog SDK does by default; a very frequent schedule adds that much event volume to the project.
• A flag PostHog does not return at all resolves to enabled: false, indistinguishable from a flag that genuinely evaluates to false. If expected_enabled is also false, a flag that stopped resolving entirely would read as compliant rather than broken; keep distinct_id pointed at an account you know the flag actually targets.
• distinct_id must be an ID PostHog's flag targeting rules actually evaluate against; a made-up ID with no history may fall back to the flag's default rather than exercising a specific rollout cohort.

Quick start

1. Add the POSTHOG_API_KEY and SLACK_WEBHOOK_URL secrets.
2. Set distinct_id and flag_key to a real flag and a user you know its current value for.
3. Set expected_enabled to match that known value and run the flow, confirming compliant.
4. Flip expected_enabled to the opposite value and re-run to confirm alert fires with DRIFT.
5. Enable the hourly trigger once expected_enabled reflects the flag's real safe state.

How to extend

• Loop over several flag_key/expected_enabled pairs with io.kestra.plugin.core.flow.Loop to watch every safety-critical flag in one scheduled run.
• Watch the same flag across several distinct_id values representing different rollout cohorts, to catch a cohort-specific regression rather than only a single canary account.
• Chain io.kestra.plugin.posthog.Capture after a DRIFT result to record a synthetic flag_drift_detected event back into PostHog's own analytics for trend tracking.

Links

• PostHog plugin: https://kestra.io/plugins/plugin-posthog
• PostHog feature flags API: https://posthog.com/docs/api/flags
• Slack incoming webhooks: https://api.slack.com/messaging/webhooks