--- title: SDK Health Hub Warnings description: "Troubleshooting reference for Statsig Health Hub messages in the console, covering SDK health, data freshness, and pipeline status indicators." product: general last_updated: 2025-09-18 token_estimate: 2144 --- # SDK Health Hub Warnings > For AI agents: a documentation index is available at [/llms.txt](/llms.txt). Append `.md` to any page URL for markdown, or send `Accept: text/markdown`. ### Detecting Initializations Initialization is the step in SDK setup where your SDK downloads the values for your Flags (Gates), Experiments, Dynamic Configs, and other configs. During initialization, the SDK also prepares to log events. In all SDKs, initialization requires calling a method like `.initialize()`, with occasional naming variation between SDKs (for example, `InitializeAsync` in JavaScript). _How to solve:_ If you're using a less common SDK (.NET, Dart, Unity, PHP) or an older version, this section can appear incomplete by mistake. Otherwise, initialize your SDK. Go to [the docs for the SDK you're using](https://docs.statsig.com/sdks/getting-started). ### Initialization Success Initialization success is the percent of initialization attempts that successfully return values from the Statsig servers. _How to solve:_ Common issues on client SDKs include adblockers, poor network conditions, or `initialize/updateUser` calls made without a network connection (common with backgrounded Android apps). If you suspect adblockers, consider setting up a [proxy](https://docs.statsig.com/infrastructure/api_proxy/custom_proxy). Poor network conditions are difficult to resolve. Server issues are less common. They may include improper networking restrictions in your cluster, or an unsuccessful custom initialization approach such as an improperly configured data adapter. Check the specific error logs where your Server SDK is running for more information. ### Initialization Size As you add more gates, experiments, and dynamic configs to your project, the size of the `initialize()` payload grows. On client SDKs, the initialize payload is "evaluated," meaning it contains only the results for a single user. On server SDKs, the payload contains the full set of rules defining the results for all users. _How to solve:_ Archive stale gates and experiments, and limit the size of any dynamic configs you use. Statsig doesn't recommend storing large amounts of data in Dynamic Configs. [Target Apps](https://docs.statsig.com/sdks/target-apps) limit the configs any one client/server key can retrieve, typically to only those needed. ### Initialization Time Statsig serves initialization from CDNs for Server SDKs and from its own servers for Client SDKs. Clients' network conditions largely drive initialization time, but initialization payload size can also contribute. _How to solve:_ Reduce your initialize size by archiving stale gates and experiments and limiting dynamic config size. ### Detecting Config Checks Any time you call `.checkGate`, `.getExperiment`, `.getDynamicConfig`, or a similar method in the Statsig SDKs, the SDK sends a "check" event to Statsig's servers. These check events let you see usage of your configs and understand user allocation to experiments. If you're using Statsig's gates, experiments, or dynamic configs in your app, you should see data in this field. _How to solve:_ On client SDKs, adblockers can block exposure data. The SDK can also lose exposure events when users are redirected immediately after a "check", before the SDK sends the event. On server SDKs, a common issue is that the process exits before the SDK sends events, which is typical in serverless situations. Calling `.shutdown` or `.flush` on the SDK prevents the process from exiting before it sends events. Refer to your SDK reference docs. Another common issue is accidentally disabling exposure logging on your checks or in `StatsigOptions`, or misconfiguring an event logging API in `StatsigOptions`. ### Config ID Presence Every config (gate, experiment, or Dynamic Config) in Statsig has an ID type used to randomly bucket users into groups. When that ID is absent from your "checks", Statsig can't accurately bucket those users. Statsig places all users without the ID in the same bucket, which can unbalance your experiment. _How to solve:_ Review your code paths to ensure the ID type is correct for where the experiment runs. For logged-out experiments, an anonymous identifier like StableID is most appropriate. You can also add a targeting gate to the experiment to filter out users with a null ID type. ### Healthy Evaluation Reasons When you check a Statsig gate, experiment, or dynamic config, the SDK always provides a value to ensure the customer experience is unaffected if something goes wrong. The SDKs expose "Evaluation Reason" as a key indicator of whether the SDK is in a healthy state when you make checks. The [debugging docs](https://docs.statsig.com/sdks/debugging#evaluation-reason) discuss reasons in detail. _How to solve:_ - If your evaluation reason looks like `uninitialized`, `unrecognized`, `novalues`, or `loading`, review your [Initialization Strategy](https://docs.statsig.com/client/concepts/initialize). `uninitialized` means you didn't call `initialize`. `loading` and `novalues` often mean that you're checking a config before initialization returns, or that initialization succeeded but returned no values for the user object you're using (for example, you called `updateUserSync()`, which changes the user without fetching new values for them). - If your evaluation reason looks like `error` or `unsupported`, update your SDK version. These reasons indicate that you're attempting to use a rule type that your SDK version doesn't support. - If your evaluation reason looks like: `bootstrapstableidmismatch` or `invalidbootstrap`, refer to the [debugging guides](https://docs.statsig.com/sdks/debugging#faqs) for these issues. - If your evaluation reason looks like `noclient`, then you might be trying to check a config outside of the in React. ### Detecting Events In Statsig, you can use the `.logEvent()` method in any SDK to create metrics that support your experiments. Without events, experiment analysis and Metrics Explorer are unavailable. If you're using Statsig Warehouse Native, this section might appear empty. _How to solve:_ If you already have a source of events, import them through one of the [Integrations](https://docs.statsig.com/integrations/introduction) or using a data import from your [warehouse](https://docs.statsig.com/data-warehouse-ingestion/introduction). Otherwise, start tracking events with `.logEvent()` in your code. Events may not reach the Statsig platform in two cases: if you have a misconfigured `StatsigOption` (such as `disableAllLogging`), or if you aren't calling `.flush` or `.shutdown` before your process exits. The second case is most common in serverless applications. ### Event ID Presence For an event to be useful in Statsig, it should have at least one ID attached, such as a userID, stableID, or a customID that you define. Some SDKs require at least one ID through typing, but others don't. _How to solve:_ Ensure your user objects have at least one ID. Statsig can't use events without an ID in experiment analysis. ### Latest Versions Statsig regularly updates SDKs with performance, security, and functionality improvements. Keep your SDK versions up to date. Statsig doesn't always publish official end-of-life notices, so aim to stay on a version no more than 6 months old. _How to solve:_ Go to your [SDK reference](https://docs.statsig.com/sdks/getting-started) to find the latest version. ### Client Bootstrapping [Client Bootstrapping](https://docs.statsig.com/client/concepts/initialize#2-bootstrap-initialization) uses Server SDKs to provide initialization values to client SDKs. Bootstrapping offers two benefits. First, the initialization request can run in parallel with other client requests, which reduces load times. Second, bootstrapping improves resilience during a Statsig outage, because Server SDKs have continual, uninterrupted access to rulesets. _How to solve:_ Go to the [guides on client bootstrapping](https://docs.statsig.com/client/concepts/initialize#2-bootstrap-initialization) to assess whether bootstrapping is the right initialization strategy for your use case. ### Target Applications Target Applications filter the gates, experiments, and dynamic configs that any one SDK key can access. Target Apps reduce payload sizes (a performance benefit) and limit the visibility of server-targeted configs to the frontend (a privacy benefit). _How to solve:_ Go to the [Target Apps page](https://console.statsig.com/settings/apps) in the console to set up your first target apps.