Evaluation metrics for Vercel Flags

Vercel Flags now surfaces a live evaluation view on each flag detail page. The view charts evaluations per minute over time and marks each flag version on the chart so shifts in traffic can be tied to a specific configuration change rather than inferred from logs or dashboards elsewhere.

The evaluation view supports grouping and filtering by variant, reason, environment, SDK key, client, and reporting project. That combination maps evaluation volume to who is resolving the flag, under which environment and SDK key, which variant they received, and why the resolution landed where it did. Custom clients can set a new clientName property so their traffic is labeled cleanly instead of collapsing into an anonymous or default client bucket.

For engineers shipping behind feature flags, evaluation charts with version markers close a common gap between “we changed the rule” and “something moved in production.” When evaluation rate jumps or a variant share changes right after a version mark, the flag detail page itself becomes the first place to confirm whether the change behaved as intended, without stitching metrics from a separate observability stack.

In product terms, this pushes Vercel Flags beyond a pure configuration store toward runtime visibility for the same object you edit. Filtering by environment and SDK key matters for teams that share flag definitions across staging and production or across multiple apps under one project, while reason and variant filters help separate intentional targeting from fallback or error-driven resolutions.

Practical next step: when you roll a flag version, watch the evaluations-per-minute chart for the expected volume and variant mix immediately after the version mark, and use clientName on custom clients so multi-client traffic does not blur those signals. If evaluations move without a matching version mark, check filters for environment, SDK key, and reason before assuming a config bug.