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. It also tells you when a flag is ready to be cleaned up and when your usage is heading past the plan limit.
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 and lifecycle alerts are checked every 30 minutes; usage alerts every hour.
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 stop requesting the missing key. A Config settled alert resolves once the config is archived.
Fixing the cause in the dashboard does not wait for the next check. Saving targeting rules, changing SDK availability, restoring a config from the archive, renaming a key, or changing your plan each trigger an immediate check, so the alert resolves right away.
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, or how much a projected overage would cost.
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.
- 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 outdated SDK alerts are emailed at Medium and up, usage alerts at Medium and up, and the two lifecycle alerts are not emailed.
Who receives which alerts
| Group | Received by |
|---|---|
| Application requests, SDK versions, config lifecycle | Everyone in the organization: viewers, operators, developers, admins, and owners |
| Billing usage | Owners, admins, and billing managers |
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.
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.
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.
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.
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.
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 if you want a daily reminder.
Config settled
Priority: Low. Grace period: none.
A temporary config has served the same value everywhere 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.
Config ready to archive
Priority: Low. Grace period: none.
A temporary config is no longer evaluated in any environment and can be archived.
What to do: archive it from the config's Settings tab. If an application still needs it, the alert resolves on its own the next time the config is evaluated.
Billing usage
Usage alerts are raised once per meter and threshold in a billing period and go to owners, admins, and billing managers.
Usage projected to exceed the limit
Priority: Low to Critical, by the projected overage cost.
Usage for the month on one of the plan's meters (client sessions, service connection hours, or Admin API requests) is above 70% or 90% of the plan limit and, at the current rate, on track to exceed it. On the Free plan, which has no overage rates, the alert is always Critical.
What to do: review the Billing & Usage page, which shows each meter against its limit. Upgrade the plan if the growth is expected.
Usage limit exceeded
Priority: Low to Critical, by the overage cost.
Usage for the month has exceeded the plan limit on a meter. On paid plans the overage is billed at the rates on the pricing page.