Alerts

ConfigDirector watches the evaluations your applications report and alerts you when they show a problem: a config key that does not exist, a config requested as the wrong type, an in-code default value that the targeting rules can never serve, an SDK that is out of date or too old to evaluate the segments your rules use. It also tells you when a flag is ready to be cleaned up, when an experiment's run does not split its contexts the way you configured, when one of its guardrails is likely worse for a variation, when its primary metric is likely better or likely worse for a variation, when an environment reaches its daily cap of tracked events while an experiment runs there, when your spend is heading for the spending limit, when a Free organization's usage is heading past the free allowance, and when a webhook or an integration was disabled because deliveries to it kept failing.

There is nothing to configure. Alerts are raised for every organization and appear in the dashboard; you choose which ones also reach your email.

Where alerts appear

Alerts in the sidebar shows a count of unread alerts, colored by the highest priority among them. The alerts page has three tabs:

• Inbox: open alerts. Select one or more to mark them as read or dismiss them.
• History: alerts you dismissed and alerts the system resolved, kept for 30 days.
• Muted: what your organization has muted; see Muting.

Each alert has a detail page with a plain-language summary of what was found, the environment and SDK key involved, how many evaluations were affected and from which SDKs and versions, when it was last seen, and a What to do section.

Read and dismissed states are per user, so dismissing an alert does not hide it from your teammates.

How alerts are detected and resolved

Application, outdated SDK version, lifecycle, and experiment alerts are checked every 30 minutes. Usage alerts are checked every hour, and so are the alert for server SDKs that cannot evaluate segments and the alerts for a webhook or an integration disabled after repeated failures.

An alert is raised when a check finds its condition. You do not resolve alerts yourself: an alert is resolved automatically when a later check no longer finds the condition. A Config not found alert resolves once the applications have stopped requesting the missing key for the alert's quiet window, a wait sized from how often they usually requested it; see Dynamic Detection. A Config settled alert resolves once the config is no longer settled, or once the applications stop evaluating it or a code scan no longer finds it in the code; see Dynamic Detection.

Fixing the cause in the dashboard does not wait for the next check. Saving targeting rules, shipping a variation or stopping a run, changing SDK availability, changing a config's lifetime, updating a feature flag to a kill switch or back, archiving a config, restoring a config from the archive, renaming a key, changing the spending limit or a billing alert threshold, switching between Free and Pay as you go, or enabling or deleting a webhook or an integration each trigger an immediate check, so the alert resolves right away. The one exception is the SDK cannot evaluate segments alert, which resolves at its next hourly check.

Some kinds wait until the condition has been present continuously for a grace period before alerting, so a brief blip during a deployment does not alert anyone. The grace periods are listed with each kind below.

Priorities

Every alert has a priority: Low, Medium, High, or Critical. Some kinds always have the same priority. Others carry a range, and the priority is decided by what was found: how large a share of evaluations were affected, whether the config is a kill switch, whether the environment is live, how close spend is to the spending limit, or the priority chosen for a billing alert threshold.

Dismissing

Dismissing an alert removes it from your inbox. For application, SDK version, experiment split, and experiment guardrail alerts, a dismissal works like a snooze: if the condition is still occurring after 7 days (14 days for the in-code default value mismatch), the alert returns to your inbox. Lifecycle, experiment result, daily cap of tracked events, usage, webhook, and integration alerts stay dismissed until they resolve.

Muting

Muting is for a problem your team has decided is fine, such as an in-code default value you keep on purpose. A mute stops one kind of alert about one subject, for example an in-code default value mismatch on one config, and it applies to everyone in your organization until someone unmutes it.

To mute an alert, open it and choose Mute. You can mute it in the alert's environment only, or in all environments of the project, including environments created later. You can add a note to tell your teammates why.

Muting resolves the alert right away. Muting in all environments also resolves the same alert in the project's other environments. ConfigDirector keeps checking for the problem while it is muted, so if it is still happening when someone unmutes it, the alert comes back at the next check.

Billing, usage, lifecycle, outdated SDK version, experiment, webhook, and integration alerts cannot be muted.

The Muted tab on the alerts page lists your organization's mutes with who muted each one, when, and their note. Unmute one from there.

Everyone in the organization can see the mutes. Operators, developers, admins, and owners can mute and unmute alerts.

Email delivery

Open Email preferences on the alerts page to choose, for each kind, the lowest priority worth an email. The setting is per organization and applies to you only. Every alert still appears in the dashboard regardless of the email setting.

The list follows the organization's pricing option. A Free organization lists the two free allowance alerts, and a Pay as you go organization lists the two spending limit alerts instead; a preference saved under one option is kept and applies again if the organization switches back. Billing alert thresholds have no email preference: each threshold is emailed to owners, admins, and billing managers at the priority chosen for it on the Billing & usage page. The service suspended alert of a Free organization has no email preference either: it is always emailed right away.

• Critical alerts are emailed as soon as they are raised.
• Everything else is collected into one daily digest.

By default the integrity alerts (config not found, availability violations, type mismatch) are emailed, in-code default value, SDK version, experiment split, and experiment guardrail alerts are emailed at Medium and up, the experiment result and daily cap of tracked events alerts are emailed, the billing alerts of the organization's option are emailed, the webhook disabled and integration disabled alerts are emailed, and the two lifecycle alerts are not emailed.

Who receives which alerts

Alert kinds

Application requests

These are the integrity alerts. They are detected from the evaluations themselves, so they catch mistakes in code that compiles and deploys fine, in any of the SDKs, without any instrumentation on your side.

Config not found

Priority: High. Grace period: none.

An application requested a config key that does not exist in the project, and received its in-code default value. The usual causes are a typo in the key, a config created in a different project, a config that was archived while code still reads it, or code that shipped before the config was created.

What to do: create the config, restore it from the archive, or fix the key in the application. The alert names the SDK key and the SDKs that asked, which tells you which application to look at.

The alert resolves when the config is created, or once no application has requested the key for the alert's quiet window. The quiet window is sized from how often the key was usually requested, kept between 1 hour and 7 days; see Dynamic Detection.

Client SDK requested a server-only config

Priority: High. Grace period: none.

An application using a client SDK requested a config whose SDK availability excludes client SDKs. The application received its in-code default value.

What to do: if the config is meant to be used in the client, add client SDKs to its availability. If it is not, remove the evaluation from the client application; the alert is telling you that a value you chose to keep server-side is being asked for from the client.

The alert resolves when the config is made available to client SDKs, or once no client SDK has requested it for the alert's quiet window. The quiet window is sized from how often client SDKs usually requested the config, kept between 1 hour and 7 days; see Dynamic Detection.

Server SDK requested a client-only config

Priority: High. Grace period: none.

The reverse case: a server SDK requested a config that is only available to client SDKs. It resolves the same way: when the config is made available to server SDKs, or once no server SDK has requested it for the alert's quiet window.

Config type mismatch

Priority: High. Grace period: none.

An application requested a config as a data type that does not match the config's type, for example getString on a boolean flag, or a JSON value that could not be parsed. The SDK returned the in-code default value instead.

What to do: fix the call in the application to use the config's type, or change the config's type if the code is right. The alert lists the SDKs and versions that made the mismatched requests.

The alert resolves once no application has requested the config as that type for the alert's quiet window. The quiet window is sized from how often the mismatched requests usually happened, kept between 1 hour and 7 days; see Dynamic Detection.

In-code default value mismatch

Priority: Medium, or High if the default was actually served. Grace period: 5 days.

An application carries an in-code default value that none of the targeting rules in that environment can serve. For a boolean flag that means the in-code default is true while every rule serves false, or the other way around; for other types it means a value that no rule mentions. The in-code default value is what your users get when the SDK cannot evaluate the config, so a default the rules would never serve is a behavior your users can hit and you never tested.

Kill switches are not covered, because a kill switch's in-code default value is chosen for safety and is expected to differ from what the rules serve day to day. A feature flag that becomes a kill switch has its open mismatch alerts resolved right away.

What to do: align the in-code default value with the default targeting rule value, or add the value to the rules if it is intentional. The 5-day grace period exists because the mismatch is often temporary while a rollout changes the rules.

The alert also resolves once no application has used a mismatching in-code default for the alert's quiet window. The quiet window is sized from how often the mismatch usually happened, kept between 1 day and 14 days; see Dynamic Detection. If you archive the config, the alert resolves right away. The alert is raised, and stays open, only while the config is still in use: applications still evaluate it, or a recent code scan still finds it in the code, judged by how often it is usually evaluated; see Alerts that ask for a code change.

In-code default value served too often

Priority: Medium; High when defaults are half or more of evaluations; one step higher for kill switches, up to Critical. Grace period: 2 days, or none when Critical.

An application fell back to its in-code default value for at least 10% of its evaluations of a config in an environment, over at least 100 evaluations in the last 24 hours. The alert lists the reasons the SDK reported, such as the config not being available to that SDK, a type mismatch, or evaluation before the client was ready.

What to do: the reasons point at the cause. Evaluations before the client is ready are usually fixed by awaiting initialization in the application; the other reasons correspond to the alerts above.

The alert resolves once no application receives the in-code default value for the alert's quiet window. The quiet window is sized from how often this usually happened, kept between 1 day and 14 days; see Dynamic Detection. If you archive the config, the alert resolves right away. The alert is raised, and stays open, only while the config is still in use: applications still evaluate it, or a recent code scan still finds it in the code, judged by how often it is usually evaluated; see Alerts that ask for a code change.

SDK versions

Outdated SDK version

Priority: Medium. Grace period: 2 days.

An SDK version that ConfigDirector no longer recommends is connected to one of your environments. The alert names the SDK, the version, the SDK key, and how many connections were seen.

What to do: upgrade the SDK. The SDK reference lists the current versions.

The alert resolves once no application has connected with that version for the alert's quiet window. A connection counts until it closes, so an application that stays connected keeps the alert open. The quiet window is sized from how often applications usually connected with that version, kept between 1 day and 14 days; see Dynamic Detection.

SDK cannot evaluate segments

Priority: Medium, or High in a live environment. Grace period: none.

In the last 24 hours, an application connected to an environment with a server SDK version too old to evaluate segments, and the targeting rules of at least one config in that environment use a segment. ConfigDirector never sends that version a rule with a segment condition, so for the applications running it those rules are skipped and the next rule applies. The alert names the SDK, the version, the SDK keys it connected with and how many connections each had, and how many configs in the environment use segments. Client SDKs never raise it, because ConfigDirector evaluates segments for them.

What to do: upgrade every application that connects to the environment with that version. Server SDK versions lists the versions that evaluate segments. The alert resolves once that version has not connected to the environment for the alert's quiet window, or once no config in the environment uses a segment. Saving targeting rules does not resolve it right away; the next hourly check does. The quiet window is sized from how often applications usually connected to the environment with that version, kept between 1 day and 14 days; see Dynamic Detection.

Config lifecycle

These two alerts turn the config lifecycle into a to-do list. They are raised for temporary configs only: a permanent config is never reported as settled or ready to archive, because it is expected to stay. They are Low priority and not emailed by default; turn them on in Email preferences to get each new one in the daily digest.

Config settled

Priority: Low. Grace period: none.

A temporary config has served the same value in every live environment for its role's horizon (7 days for a feature flag, 14 for an experiment, 30 for a config) and can be hardcoded and removed. The settled value is shown on the config page.

What to do: hardcode the value in your applications and deploy. The alert resolves once the applications stop evaluating the config or a code scan no longer finds it in the code, judged by how often it is usually evaluated; see Alerts that ask for a code change. Once the applications stop evaluating the config, it also becomes ready to archive. If you archive the config before then, the alert resolves right away. If you are keeping the config, update a feature flag's role to kill switch, or a config's lifetime to permanent, and the alert resolves right away too.

Config ready to archive

Priority: Low. Grace period: none.

A temporary config has gone its quiet window without an evaluation in its live environments and can be archived. The alert shows how long the config's quiet window is and says which environments were counted: only the live ones, or every environment when the config has no recent live use to judge by. The quiet window is sized from how often the config is usually evaluated; see Dynamic Detection.

What to do: archive it from the config's Settings tab, and the alert resolves right away. If an application still needs it, the alert resolves on its own once the config is evaluated again in a live environment, or once an application anywhere evaluates it every working day. If you are keeping the config, update a feature flag's role to kill switch, or a config's lifetime to permanent, and the alert resolves right away.

Experiments

These alerts tell you what you would otherwise learn only on an experiment's Experiment tab. The split, guardrail and result alerts are about the open run of an experiment in one environment. A run has at most one open alert of each of these kinds, except that it can have two result alerts: one for a variation that is likely better and one for a variation that is likely worse. The daily cap of tracked events alert is about an environment, and names every run open there.

A guardrail or a primary metric that sits right at the line between two verdicts can cross it many times as the numbers refresh. So the guardrail and result alerts are raised only once the verdict has been read at every check for a day, and an open alert resolves only once the chance to beat control of the result it names has clearly moved back, not the moment the Results panel reads No clear difference again. While that chance stays close to the verdict, the open alert keeps the numbers and the priority from the last check that read the verdict; the Results panel has the current ones. A run that ends within a day of the verdict first being read does not raise these alerts.

Experiment split does not match its configured shares

Priority: Medium; High when a variation's share of the exposures is more than 10 percentage points away from its configured share; one step higher in a live environment, up to Critical. Grace period: none.

The contexts exposed during a run are split between the variations differently from the shares the rollout configures, by more than chance explains. This is the mismatch warning of the Exposures card, and it means the results of the run are not reliable. The alert names the variation furthest from its configured share, with the share of the exposures it received as the Exposures card shows it, and when the run has several rollouts, the rollout that is furthest off.

What to do: the usual causes are contexts that evaluate without a stable identifier and a rule above the split that catches part of the traffic. Use the rule tester on the experiment's page to look for the cause and fix it, then stop the run and start a new one, so the counts start over.

The alert resolves once the split matches the configured shares again, and right away when the run ends, which happens when you ship a variation, stop the run, or save targeting rules that change or remove the rollout, or when you archive the experiment.

Experiment guardrail likely worse

Priority: Medium; High when the variation's chance to beat control is under 1%, or when the variation is more than 10% worse than the control on the guardrail; one step higher in a live environment, up to Critical. Grace period: 1 day.

During a run, a guardrail of the experiment has read Likely worse for a variation at every check for a day. This is the guardrail warning of the Results panel. The alert names the guardrail and its metric kind, the variation and the control, with the variation's chance to beat control and its lift. When several guardrail results are likely worse, the alert names the one at the highest priority and, among those, the one least likely to beat the control; the Results panel lists them all. Like every result, it waits until each variation of the rollout has enough exposures.

What to do: check the guardrail on the Results panel before you ship the variation, and treat it as a reason not to ship that variation, even when the primary metric reads Likely better. If the variation is doing harm, stop the run or ship another variation.

The alert resolves once no guardrail of the experiment is likely worse for a variation in the run and the result it names has clearly moved back, and right away when the run ends or you archive the experiment. If a guardrail reads likely worse again later in the same run, a new alert is raised after another day.

Experiment result reached

Priority: Low. Grace period: 1 day.

During a run, the primary metric of the experiment has read Likely better or Likely worse for a variation at every check for a day, on the metric kind the primary metric decides on. The alert names the primary metric and its metric kind, the variation and the control, with the verdict, the variation's chance to beat control and its lift. When several variations are likely better, the alert names the one with the highest chance to beat control. A variation that is likely worse gets an alert of its own, which names the one least likely to beat the control when there are several. The Results panel lists them all. Like every result, it waits until each variation of the rollout has enough exposures. An experiment without a primary metric does not raise this alert.

What to do: read the Results panel, guardrails included. A verdict is a reading of the data so far, so if you decided how long the run would go, wait until then; Reading results well says why. When you are ready, ship the variation or stop the run.

The alert resolves once no variation reads that way on the primary metric and the variation it names has clearly moved back, and right away when the run ends or you archive the experiment. If the primary metric reads that way again later in the same run, a new alert is raised after another day.

Daily cap of tracked events reached

Priority: High; Critical in a live environment. Grace period: none.

An environment reached its daily cap of tracked events, so ConfigDirector drops the tracked events reported there until the day ends at midnight UTC. The results of every experiment run open in the environment are missing those events. The alert says when the cap was reached and names the runs open in the environment. It is raised only while a run is open there; once raised, it stays open until the day ends, even if those runs end.

What to do: find the application that reports the most tracked events to the environment. The Live feed shows how many tracked events ConfigDirector stored from each report, and their names. Keep only the track calls your metrics need, and call track once when an outcome happens, not on every render or retry. Tracked events lists the limits.

The alert resolves at the first check after the day ends at midnight UTC. If the environment reaches the cap again the next day, a new alert is raised.

Billing

Billing alerts go to owners, admins, and billing managers. The three spend alerts belong to Pay as you go organizations and the two free allowance alerts to Free organizations; switching between them resolves the open alerts of the other option. They are checked every hour and raised once per billing cycle for each spending limit amount, billing alert threshold, or billing metric. Raising a spending limit or a threshold during the month arms its alerts again, and lowering one below the month's spend fires its reached alert at the next check. Changing or removing a limit or a threshold resolves its open alerts right away.

Spend projected to reach the spending limit

Priority: High at 70%, Critical at 90%. Grace period: none.

A Pay as you go organization's spend for the month is above 70% or 90% of its spending limit and, at the current rate, on track to reach it before the billing cycle ends.

What to do: review the month's spend on the Billing & usage page. Raise or remove the spending limit if the growth is expected, or leave it in place to cap the invoice.

Spending limit reached

Priority: Critical. Grace period: none.

Spend for the month has reached the spending limit. Service is suspended for the rest of the billing cycle: SDK connections are refused, applications fall back to their in-code default values, and the Admin API and the MCP server refuse requests. Nothing above the limit is charged. See Spending limit.

What to do: raise or remove the spending limit on the Billing & usage page to resume service right away, or leave it until the next billing cycle starts.

Billing alert threshold reached

Priority: the priority chosen for the threshold: Medium, High, or Critical. Grace period: none.

Spend for the month has reached one of the organization's billing alert thresholds. Reaching a threshold never affects the service; it is a heads-up about the invoice to come. A threshold above the spending limit never fires, so the thresholds follow the invoice, which never exceeds the limit. This kind has no email preference: the priority chosen for the threshold decides the email, Critical right away and Medium or High in the daily digest.

What to do: review the month's spend and adjust the thresholds on the Billing & usage page.

Usage projected to exceed the free allowance

Priority: Critical. Grace period: none.

A Free organization's usage of a billing metric (monthly active users, service connection hours, or Admin API requests) for the month is above 70% or 90% of the free allowance and, at the current rate, on track to exceed it.

What to do: review the Billing & usage page, which shows each metric against the free allowance. Start pay as you go if the growth is expected.

Free allowance exceeded

Priority: Critical. Grace period: none.

A Free organization's usage of a billing metric for the month has exceeded the free allowance. The billing grace period of 7 days starts, and the alert names the date and time it ends. After that, service is suspended until pay as you go starts or the next billing cycle begins.

What to do: start pay as you go on the Billing & usage page within the billing grace period.

Service suspended: free allowance exceeded

Priority: Critical. Grace period: none.

The billing grace period of a Free organization has ended with usage still over the free allowance, and service is suspended: SDK connections are refused, applications fall back to their in-code default values, and the Admin API and the MCP server refuse requests. The alert names the metrics over the allowance and when the suspension started. This kind has no email preference: it is always emailed right away. See The free allowance.

What to do: start pay as you go on the Billing & usage page to reinstate the service right away, or wait for the next billing cycle.

Integrations

These alerts go to owners and admins, who manage the organization's webhooks and analytics integrations.

Webhook disabled after repeated failures

Priority: Critical. Grace period: none.

Deliveries to one of the organization's webhooks were attempted on each of the last three days and none of them succeeded, so ConfigDirector disabled the webhook and abandoned the deliveries still waiting. Webhook events that happen while the webhook is disabled are not delivered later. The alert names the webhook and its URL, and shows the receiver's last response status or connection error.

What to do: check that the receiver at the webhook's URL is reachable and answers with a 2xx status, then enable the webhook again on its page, or delete it if you no longer need it. The alert resolves right away when the webhook is enabled again or deleted.

Integration disabled after repeated failures

Priority: Critical. Grace period: none.

Deliveries to one of the organization's analytics integrations were attempted on each of the last three days and none of them succeeded, so ConfigDirector disabled the integration and abandoned the deliveries still waiting. Experiment runs that start or end while the integration is disabled are not marked later. The alert names the integration and its tool, and shows the tool's last response status or connection error.

What to do: check that the tool still accepts the integration's credentials and settings, replace a credential or fix a setting from Edit, then click Enable on the integration's page, or delete the integration if you no longer need it. The alert resolves right away when the integration is enabled again or deleted.