Operators need a way to see which flags are on in each environment, and Martin Fowler's article recommends providing one. Build it as an authenticated, internal endpoint or dashboard, never a public page. A flag status view that anyone can read is a preview of your roadmap and a map of your weak spots.
The recommendation
Fowler's article says that embedding build and version numbers into a deployed artifact has long been helpful, and the same idea should apply to flags. Any system using flags should give operators some way to discover the current toggle configuration. In HTTP-based service systems this is often a metadata API endpoint, and he points to Spring Boot's Actuator endpoints as an example.
During an incident, "what is actually on right now" is among the first questions.
What can leak
A public or weakly protected status endpoint can reveal several things.
Unreleased features, by name. A flag called new-payments-flow tells competitors and attackers something.
Disabled protections. If a flag named strict-upload-validation is false, you have advertised a weakness.
Internal structure. Service names, customer segment names and rollout percentages show how the system is built.
Rollout state for specific customers, if targeting rules are included.
A safe design
Put the status view behind your normal internal authentication, the same one used for admin tools, and restrict it by role. Do not expose it on the same public host and path scheme as your product API unless authentication is enforced.
Return the minimum. Flag key, current value in this environment, and a last-changed time are usually enough. Leave out targeting rules and user lists unless an operator role needs them.
Add a version or hash of the whole configuration. Operators can then compare environments quickly, and automation can alert when staging and production diverge in ways nobody planned.
Human-readable descriptions
Fowler also suggests keeping base flag configuration in a structured, readable file under source control, with a description for each flag, since it helps people outside the core team decide whether to flip it. Show that description in the status view, along with an owner and an expiry date. It turns the view into a map of what to clean up.
Do not rely on obscurity for client flags
If flags are evaluated in the browser, the values reach the user anyway. Keep the client payload to what the UI needs, use opaque keys for sensitive features, and never include flags in client code that reveal control states you would not want read.
Test the exposure
Request the status endpoint without credentials from outside your network. It should fail. Request it with a low-privilege user's credentials. It should also fail unless that role is meant to see it. Add both checks to your regular external scan or to a test that runs after deploys.
Pair it with change history
A status view tells you now. Your change log, covered in who can change a feature flag, tells you how it got there.
Quick check
Should the flag status endpoint be public?
No. Keep it behind internal authentication with role limits. It can reveal unreleased features and disabled protections.
What should the status view show?
Flag key, current value per environment, last change time, an owner and an expiry date. Leave out targeting rules unless a role needs them.
Sources
Last reviewed: 19 October 2026.
