internal links

Author: ivanagas

contents/blog/best-feature-flag-software-for-developers.mdx

@@ -210,7 +210,7 @@ DevCycle is a feature flag platform that prioritizes speed, simplicity, and tigh
 
 DevCycle supports boolean and multivariate flags, percentage rollouts, user targeting, and environment management. It integrates with GitHub and Jira for flag lifecycle management, and includes built-in stale flag detection to help teams clean up technical debt.
 
-What sets DevCycle apart is its obsession with developer workflow. It supports CLI and IDE-first ways to work with flags, plus integrations with tools like GitHub and Jira so flags show up naturally in code review and planning. And their edge and local-bucketing style options help keep evaluation fast without you managing a full flag platform yourself.
+What sets DevCycle apart is its obsession with developer workflow. It supports CLI and [IDE-first ways to work with flags](/docs/vscode-extension/flag-management), plus integrations with tools like GitHub and Jira so flags show up naturally in code review and planning. And their edge and local-bucketing style options help keep evaluation fast without you managing a full flag platform yourself.
 
 DevCycle offers a free tier for up to 1,000 MAUs, with paid plans based on MAU volume.
 

contents/docs/feature-flags/best-practices.mdx

@@ -68,7 +68,7 @@ For example, at PostHog we often roll out the flag to just the responsible devel
 
 ## 8. Clean up after yourself
 
-Leaving flags in your code for too long can confuse future developers and create technical debt, especially if it's already rolled out and integrated. Be sure to remove stale flags once they are completely rolled out or no longer needed.
+Leaving flags in your code for too long can confuse future developers and create technical debt, especially if it's already rolled out and integrated. Be sure to [remove stale flags](/docs/vscode-extension/stale-flag-cleanup) once they are completely rolled out or no longer needed.
 
 When you have many flags to clean up, use [bulk delete](/docs/feature-flags/creating-feature-flags#deleting-feature-flags-in-bulk) to select and delete multiple flags at once. Select flags using checkboxes (shift-click to select a range), or filter by name or status and use "select all matching" to select all flags that match your criteria. PostHog validates that flags aren't used by experiments, early access features, or other dependent flags before deletion.
 

contents/docs/feature-flags/cutting-costs.mdx

@@ -42,7 +42,7 @@ The number of `/flags` requests and the number of `$feature_flag_called` events
 
   Active feature flags you're not using in your code are still evaluated (and charged) every time the `/flags` endpoint is called. This includes when surveys are loaded, as survey targeting evaluates all active flags to determine eligibility.
 
-  To stop charges for unused flags, you must **disable, delete, or archive** them in the PostHog UI – simply removing them from your code is not enough.
+  To stop charges for unused flags, you must **disable, delete, or archive** them in the PostHog UI – [simply removing them from your code](/docs/vscode-extension/stale-flag-cleanup) is not enough.
 
 </CalloutBox>
 

contents/docs/feature-flags/manage-flags-ai.mdx

@@ -6,7 +6,7 @@ title: Manage Feature Flags with PostHog AI
 
 ## How it works
 
-When you ask PostHog AI to create a flag, it creates it with your specified key and rollout percentage, configures targeting rules based on user properties, cohorts, or groups, and sets up variants and payloads for multivariate flags. It can also search your existing flags, identify stale flags not modified recently, and help you plan flag cleanup.
+When you ask PostHog AI to create a flag, it creates it with your specified key and rollout percentage, configures targeting rules based on user properties, cohorts, or groups, and sets up variants and payloads for multivariate flags. It can also search your existing flags, identify stale flags not modified recently, and help you plan [flag cleanup](/docs/vscode-extension/stale-flag-cleanup).
 
 ## Manage existing flags
 

contents/docs/feature-flags/production-ready.mdx

@@ -156,7 +156,7 @@ Pick the context based on where the flag is actually consumed. Server-side flags
 
 A flag set to 100% of all users with no property targeting is a flag that has finished its job. It's always returning the same value – the rollout is complete, the experiment concluded, the feature is live. But the flag is still being evaluated on every request, still included in every SDK payload, and still adding to your bill.
 
-Remove the flag and hardcode the winning path. If you're not ready to remove it from code, at least archive it in PostHog so it stops being evaluated. Stale flags are the most common source of unnecessary flag evaluation cost. See [cutting costs](/docs/feature-flags/cutting-costs) for more.
+[Remove the flag](/docs/vscode-extension/stale-flag-cleanup) and hardcode the winning path. If you're not ready to remove it from code, at least archive it in PostHog so it stops being evaluated. Stale flags are the most common source of unnecessary flag evaluation cost. See [cutting costs](/docs/feature-flags/cutting-costs) for more.
 
 **An idea worth considering:** design your flag code paths with an escape hatch you control outside of PostHog. For example, a "gate flag" that your server reads once every 30 seconds (not per user) – when it's `true`, the feature is fully rolled out and your code skips the per-user flag evaluation entirely. This means you stop paying for per-user evaluations the moment a rollout is complete, even before you remove the flag from code. And you can dial it back by setting the gate flag to `false`. This is also another application of "evaluate once, not continuously" – if you cache flag results (even for stale flags), your per-evaluation costs drop to near zero while you wait for the code cleanup.