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 your spend is heading for the spending limit, and when a Free organization's usage is heading past the free allowance.

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 two 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.

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, and lifecycle alerts are checked every 30 minutes. Usage alerts are checked every hour, and so is the alert for server SDKs that cannot evaluate segments.

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, usually because the applications stopped evaluating it and it became ready to archive.

Fixing the cause in the dashboard does not wait for the next check. Saving targeting rules, changing SDK availability, changing a config's lifetime, restoring a config from the archive, renaming a key, changing the spending limit or a billing alert threshold, or switching between Free and Pay as you go 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, 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 and SDK version 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 and usage alerts stay dismissed until they resolve.

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 and SDK version alerts are emailed at Medium and up, the billing alerts of the organization's option 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, and the alert shows its current length; 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, and the alert shows its current length; 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, and the alert shows its current length; see Dynamic Detection.

In-code default value mismatch

Priority: Medium, or High if the default was actually served or the config is a kill switch. 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.

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.

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.

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.

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 7 days, or once no config in the environment uses a segment. Saving targeting rules does not resolve it right away; the next hourly check does.

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. Once the applications stop evaluating the config, it becomes ready to archive. If you are keeping the config, change its lifetime to permanent instead, and the alert resolves right away.

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. 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, change its lifetime to permanent, and the alert resolves right away.

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 (client sessions, 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.