Feature flags in PostHog Web

The PostHog web app is home base for feature flags. It's where you create a flag, decide who gets it, watch the rollout, and turn it off when you need to – all without a deploy.

Open Feature flags in PostHog to see every flag in the project with its status, type, and last-modified date. Open a flag to edit its release conditions, inspect which users match, test how it evaluates, and see the activity log of who changed what.

Before you start

1. Set up Feature Flags – install a PostHog SDK so your app can evaluate flags.
2. Open the web app – no install needed, just sign in to PostHog.

What you can do here

• Create feature flags – set up boolean, multivariate, or remote config flags and define their release conditions.
• Add flag code to your app – the snippet that reads the flag on the other side, for each SDK.
• Test your flag – check how a flag evaluates for a specific user before you widen the rollout.
• See how a flag is used – watch how often your code called a flag and which values it returned, without building an insight.
• Schedule flag changes – queue an enable, disable, or condition change for a future date, including on a recurring schedule.
• Manage early access features – let users opt themselves in and out of a flagged feature.
• Clean up stale flags – find flags nothing has evaluated recently and retire them along with the dead code.
• Manage flags with PostHog AI – describe the flag you want and PostHog AI creates or updates it, or ask it which flags have gone stale. It's an interaction mode inside the web app, not a separate surface. See Manage flags with PostHog AI.

Before you widen a rollout, the flag detail view also shows the blast radius for a release condition – roughly how many users it would affect relative to your total – so a "10% of enterprise accounts" change isn't a guess.

See how a flag is used

Open a flag and go to the Usage tab to see how often your code called it and what it returned. PostHog builds the charts from the $feature_flag_called events your SDK sends:

• Feature flag called total volume – calls over time, broken down by the value each caller received.
• Feature flag calls made by unique users per variant – a table of how many distinct users received each value. Flags that aggregate by a group count groups instead.

One date filter drives both charts, starting at the last 30 days. Your selection is stored in the URL, so you can send someone a link to the exact window you were looking at. Underneath the charts, an event table lists individual $feature_flag_called calls with the value each one returned, on its own date range.

Send enriched flag analytics from your app to get two more charts here, covering how many people viewed the feature and how many interacted with it.

These charts aren't saved insights, so they don't add anything to your insight or dashboard lists. If you want a usage dashboard you can edit, share, and subscribe to, create one by calling POST /api/projects/:project_id/feature_flags/:id/dashboard/. The flag's usage_dashboard field then points to it, and the Usage tab shows that dashboard instead of the charts above. Flags that already have a usage dashboard keep showing it, which is why older flags can look different from new ones.

Related

• Manage the same flags from your editor over MCP.
• Evaluate and manage flags programmatically with the API.
• Understand how a value gets decided in server-side local evaluation.