FeatureSignals

Toggle Categories

FeatureSignals classifies feature flags into four categories based on how long they live, how dynamic they are, and which teams typically manage them. This classification is inspired by Martin Fowler's Feature Toggles taxonomy.

The Four Categories

CategoryLifespanDynamismTypical OwnerExample
ReleaseDays to weeksStatic per deployEngineeringenable-new-checkout
ExperimentWeeks to monthsDynamic per requestProduct / Datapricing-page-test
OpsIndefiniteDynamic per requestOps / SREcircuit-breaker-payments
PermissionIndefiniteDynamic per requestProduct / Salespremium-analytics

Release Toggles

Release toggles decouple deployment from release. They let your team merge incomplete or risky features into main behind a flag and enable them when ready.

  • Default staleness threshold: 14 days
  • Set an expires_at date at creation time
  • Remove from code immediately after full rollout
  • Keep the number of active release toggles small — each one is temporary technical debt

Experiment Toggles

Experiment toggles drive A/B tests and multivariate experiments. They route each user to a variant using consistent hashing.

  • Default staleness threshold: 30 days
  • Always pair with impression tracking to measure outcomes
  • Use mutual exclusion groups to prevent experiment interference
  • Archive (don't delete) after experiment concludes

Ops Toggles

Ops toggles control operational aspects of system behavior — circuit breakers, degradation switches, maintenance modes.

  • Default staleness threshold: 90 days
  • Document the operational runbook for each toggle
  • Require admin/ops role for toggling in production

Permission Toggles

Permission toggles gate access to features for specific user segments, tenants, or pricing tiers.

  • Default staleness threshold: 90 days
  • Use segment-based targeting rules for clean permission logic
  • Pair with RBAC — only admins or sales should modify permission toggles

Setting a Category

bash
curl -X POST https://api.featuresignals.com/v1/projects/$PROJECT_ID/flags \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "key": "enable-dark-mode",
    "name": "Dark Mode",
    "flag_type": "boolean",
    "default_value": "false",
    "category": "release",
    "status": "active"
  }'

Category-Aware Flag Health

CategoryStale After
Release14 days
Experiment30 days
Ops90 days
Permission90 days

Best Practices

  1. Assign a category at creation — Don't leave flags uncategorized.
  2. Match the lifecycle to the category — Release toggles should be removed quickly; permission toggles can live indefinitely.
  3. Use status to track progress — Combine category with status for full lifecycle visibility.
  4. Filter by category in the Flag Engine — The flags list page supports category and status filters.
  5. Review categories in flag health audits — A release toggle that's been around for 6 months probably needs re-categorization.

Next Steps