Evaluation Activity

Every time one of your applications evaluates a config, the SDK reports it back to ConfigDirector. The dashboard turns those reports into per-config activity for each environment, so you can confirm that a rollout is doing what you expect, see which value your users are actually getting, and find configs that nothing evaluates anymore.

Activity is available on Free and Pay as you go and needs no setup beyond using an SDK.

What is recorded

For each evaluation the SDK reports:

• The config key and the environment, taken from the SDK key in use.
• The value that was served.
• Whether the application fell back to its in-code default value instead, and why (for example the config was not found, or it was requested as an incompatible type).
• The SDK name and version.
• The context the value was evaluated for, by context kind and identifier, when the application provided an identifier.

Client SDKs report evaluations in batches shortly after they happen. Server SDKs evaluate targeting rules locally and report aggregated counts periodically. In both cases the activity appears in the dashboard within moments of the report arriving, usually well under a minute after the evaluation.

Evaluations of keys that do not exist in the project are recorded separately. They never appear in a config's activity, because there is no config to attach them to, but they do raise a Config not found alert.

The Activity tab

Open a config and select the Activity tab. Pick the environment at the top left and a time window at the top right: the last 8 hours, 24 hours, 48 hours, 7 days, or 30 days. Times are shown in your local time zone.

Three charts are shown for the selected environment and window:

• Total evaluations: how many times the config was evaluated over time. Use it to confirm an application is live in an environment, to see traffic patterns, and to notice when evaluations stop.
• Evaluations by value: the same evaluations broken down by the value that was served. During a percentage rollout this is where you check that the split matches the percentages you configured; for an experiment, the Experiment tab does that by counting each context once. After a rollout reaches everyone, one value should account for all of the evaluations.
• Evaluations by SDK: the evaluations broken down by SDK name and version. Use it to see which applications have picked up a change, and which are still running an older SDK.

Activity in the configs list

The configs list shows an Evaluations (7 days) column for the selected environment, with a small chart and the total for the week, next to the config's lifecycle state. Under the chart, each row says when the config was last evaluated in that environment, such as "Last evaluated 3 hours ago". A config that has gone 60 days without an evaluation in that environment shows "Not evaluated in 60 days", and a New config shows nothing yet.

A config that shows "No evaluations" in every environment is a candidate for cleanup. A temporary config becomes Archive Ready once its evaluations stop for well beyond their usual pause, as Dynamic Detection explains.

Finding configs

The search box lists the configs whose key or description contains what you type, ignoring case. The Role, Type, Status and Lifetime filters take one choice each, and Tags lists the configs that have any of the tags you pick, or, with Untagged, only the configs without tags. A config has to match the search and every filter you set, and while any of them is set, the list says how many configs match. For example, choose Role: Feature flag and Status: Stale to list the flags that were created more than 15 days ago and never evaluated. Clear filters resets the search and every filter at once.

Select the Key, Status or Evaluations (7 days) header to sort the list by that column, and select it again to reverse the order. The list is sorted by key until you choose another column. Sorting by status groups the configs by lifecycle state, and sorting by evaluations puts the configs evaluated most in the selected environment over the last 7 days first.

The list shows 50 configs per page, with page controls under it when there are more. Reloading the page, coming back from a config or sharing the link with a teammate shows the list with the environment, search, filters, sort and page you chose.

Last evaluated

When you archive a config or change its SDK availability, the confirmation dialog shows when the config was last evaluated in each environment and through which SDK key, so you can see whether anything still depends on it before you go ahead.

The same information is available to AI coding tools through the MCP server's get_config_activity tool.

Activity per context

Contexts that your applications identify with an id appear on the Contexts page for their environment, with their context kind. To list only some context kinds, such as devices, select Kinds and pick them from the context kinds seen in that environment. The list then shows the contexts of any context kind you picked, and keeps your choice when you open a context and come back, or reload the page.

Open a context to see which configs were evaluated for it in a time window, and which value each one returned. This is the quickest way to answer "what did this user get" when someone reports that a feature looks different for them than expected.

To recognize a context at a glance, such as a teammate's phone you use for testing, give it a label from its details page. The label appears next to the context's identifier on the Contexts page and in the targeting rules tester. A labeled context stays on the Contexts page however long your applications go without sending it.

Tracked events

A tracked event is something your application reports happened, such as a completed checkout or a finished export. Your code reports it by calling track in a ConfigDirector SDK, or through OpenFeature's tracking API, and the SDK sends it along with its evaluation reports.

track is available in the JavaScript, React, Vue, React Native, Flutter, Swift, Android, Next.js, Nuxt, Node.js, Python, Java, .NET and Go SDKs, and through the OpenFeature Web, Swift, Android, Flutter, Node.js, Python, Java, .NET and Go providers.

A tracked event carries:

• A name, such as checkout_completed, of 1 to 150 characters.
• The context it happened for, if you give one, by context kind and identifier. An event counts for an experiment only when it carries the identifier of a context the experiment's split served, so give the context when you track the outcome of an experiment. An event without a context, or for a context without an identifier, is stored and counts for no experiment.
• A value, if you give one: a single number, such as an order total or a duration.
• Details, if you give them: an object with your own fields, such as { "plan": "team" }. A field can hold a string, a number, a boolean, or a nested object or list.
• The time it happened.

Tracked events show in two places:

• The Experiment tab. For an experiment's run, the Experiment tab lists each event name the experiment has no metric for, with the number of distinct contexts that reported it under each variation, after the split first served them that variation, and the sum across the variations. A context counts once per variation for each event name, however often it reports the event, and a context the split never served in that run is not counted. A new event shows in the counts within about 25 minutes. To compare the variations on an event, define a metric for it and attach the metric to the experiment; How ConfigDirector computes results explains the comparison.
• The Live feed. The Live feed page shows, for each report an SDK sends, how many tracked events ConfigDirector stored from it and their names.

Limits

Retention

The longest activity window available is 30 days, and the charts always have the full history they can display.

A tracked event is kept for 90 days. Removing it does not change the counts a run already shows.

A context your applications have not sent for 180 days is removed from the Contexts page, and its identifier is erased as when you delete a context. It comes back the next time they send it.

Archiving a config removes its activity along with it. If you need the numbers, take them from the Activity tab before archiving.