How ConfigCat SDKs Keep Applications Running During Outages

Outages happen. Even the best engineering teams and the most reliable infrastructure eventually run into network failures, service disruptions, or unexpected connectivity problems.

The real question is not whether a platform will ever experience an incident. It is what happens to your application when it does.

A feature flag service is often part of the path used to manage releases, disable problematic functionality, and respond to production issues. The last thing you want during an incident is for the feature flag system itself to make your application unavailable.

ConfigCat SDKs are designed to avoid that problem. They evaluate feature flags locally, keep using the latest valid configuration when refresh requests fail, and retrieve updates once connectivity returns. Your application does not need to be restarted or redeployed.

Let's look at how this fault-tolerance architecture works.

Local Evaluation: The Foundation of Fault Tolerance

When you create feature flags and targeting rules in ConfigCat, they are distributed to SDKs through a static configuration file called config.json.

The ConfigCat SDK downloads and caches this configuration, then evaluates flags inside the application process. It does not contact ConfigCat every time your code checks a flag.

This distinction is important. Once the configuration has been downloaded, the SDK can evaluate flags locally using the cached targeting rules and rollout settings. Feature evaluations remain fast, and your application does not depend on a constant connection to ConfigCat for every decision it makes.

The network is only needed when the SDK checks for an updated configuration. If a refresh request fails, the SDK can continue evaluating flags using the version it already has.

This local evaluation model is a central part of the ConfigCat architecture and one of the reasons the SDKs can remain both fast and resilient.

Why This Architecture Is Resilient by Design

ConfigCat keeps the configuration-delivery path intentionally simple.

SDKs download static configuration files from the ConfigCat CDN, cache them locally, and evaluate flags inside the application. There is no remote database query or server-side evaluation required every time a flag is checked.

Static files are also well suited to CDN caching. ConfigCat uses Cloudflare's global network to distribute configuration files closer to the applications requesting them.

This architecture has fewer moving parts in the evaluation path. Fewer moving parts generally mean fewer opportunities for a temporary infrastructure issue to interrupt your application.

More importantly, a failed configuration refresh does not erase the configuration the SDK has already downloaded. The SDK can continue evaluating flags from its last known good state.

What Happens When a Refresh Fails?

Suppose your application is running normally and the SDK already has a valid configuration in its cache. The SDK attempts its next refresh, but the request fails because of a network, DNS, routing, CDN, or service issue.

The SDK does not discard the existing configuration. Instead, it continues using that cached version for feature flag evaluation. What happens next depends on the polling mode. Auto polling tries again during a later polling cycle, Lazy loading retries when another evaluation requires a refresh, and Manual polling waits until the application explicitly requests one. Once the connection becomes available again, a later refresh succeeds and the SDK replaces the cached version with the latest one.

The application does not need to restart to recover.

During the incident, your application may temporarily use an older configuration. That means a newly changed flag might take longer to reach the affected instances. However, evaluations can continue using configuration that was previously downloaded and successfully validated.

The tradeoff is temporary configuration staleness rather than application unavailability.

A Practical Outage Example

Consider a backend service using auto polling with the default 60-second refresh interval.

At 10:00 a.m., the SDK downloads a configuration in which a new recommendation engine is enabled for 10% of users.

At 10:01 a.m., the backend service temporarily loses access to the ConfigCat CDN. The next refresh fails, but the SDK continues evaluating the flag locally using the configuration downloaded at 10:00 a.m.

At 10:04 a.m., someone increases the rollout from 10% to 25% in the ConfigCat Dashboard. Because the service cannot retrieve the new configuration yet, it continues using the previous 10% rollout.

At 10:07 a.m., connectivity returns. The next refresh succeeds, the SDK updates its cache, and subsequent evaluations use the 25% rollout.

Throughout the incident, the application continues running and evaluating the flag. It does not receive the latest change immediately, but it does not need to be restarted either.

This behavior also applies to targeting rules and percentage-based releases. Those rules are part of the cached configuration and are evaluated locally by the SDK. If you are using flags for gradual delivery, our guide to canary releases with feature flags explains how to combine percentage rollouts with production monitoring.

What If There Is No Cached Configuration?

There is one important edge case: a new application instance starts while ConfigCat is unreachable and no valid configuration is available in its cache.

In this situation, the SDK has no valid ConfigCat configuration from which to evaluate the requested flag. If the SDK cannot calculate a value, the evaluation method returns the default value supplied by the application. Depending on the SDK and API, it can also report the error through logging or evaluation details.

For example:

const useNewRoutingEngine = await configCatClient.getValueAsync("use_new_routing_engine", false);

Here, false is the application-defined default. If the SDK cannot evaluate the flag because of an error, the service continues using the existing routing engine rather than switching to the new one without a valid configuration.

This keeps the application behavior deterministic, but only when the default value has been chosen carefully.

For an experimental algorithm, the safest default may be to preserve the established implementation. For a non-essential integration, it may be better to keep the integration disabled. A critical operational flag may need a different fallback depending on the consequences of failing open or failing closed.

The default value is not just a required SDK argument. It is the final layer of your feature flag fault-tolerance strategy. ConfigCat SDKs use the supplied default value when a flag cannot be evaluated successfully, including when no valid configuration is available.

Choosing the Right Polling Mode

ConfigCat SDKs support three polling modes, giving you control over how configuration updates are downloaded.

Auto polling

Auto polling is the default mode. The SDK checks for updated configuration in the background every 60 seconds by default, while evaluations continue using the locally cached version.

This is usually the most convenient option for long-running services and applications that should receive feature flag changes automatically.

Lazy loading

In lazy loading mode, the SDK retrieves an updated configuration when your application requests a flag and the cached entry has expired. The default cache time to live is 60 seconds, although it can be configured.

This mode can suit workloads where flags are evaluated less frequently or where a continuous background poller does not fit the application lifecycle.

Manual polling

Manual polling gives your application full control over refresh timing. The SDK downloads a newer configuration only when your code explicitly requests it.

This can be useful when configuration refreshes need to align with a scheduled task, a controlled application lifecycle, or another operational event.

Although the refresh behavior differs, all three modes rely on cached configuration for evaluation. Their platform-specific options are covered in the ConfigCat polling and caching documentation.

In-Memory, Persistent, and Shared Caching

By default, ConfigCat SDKs store the configuration needed for feature flag evaluation in memory.

For a long-running application, that may be sufficient. If a refresh fails, the running process can continue evaluating flags from its in-memory configuration.

The limitation is that an in-memory cache disappears when the process stops.

This matters for serverless functions, short-lived workers, PHP processes, frequently recycled containers, and other workloads that start and stop regularly. If a new instance starts during an outage, it may have no configuration to evaluate.

For these environments, ConfigCat SDKs support custom cache implementations. Depending on the SDK and platform, the client can use persistent or shared storage instead of relying entirely on process memory.

A persistent cache lets a newly started process reuse configuration downloaded by an earlier instance. In SDKs that support shared caching, multiple clients can access the same stored configuration.

Some SDKs also support offline operation. In this model, an SDK evaluates flags from a configured cache or local source without making HTTP requests. This makes it possible to separate configuration retrieval from evaluation when the architecture requires tighter network control.

Adding ConfigCat Proxy

Teams that need another layer of control can deploy ConfigCat Proxy inside their own infrastructure.

The Proxy can sit between your applications and the ConfigCat CDN to:

• cache feature flag configuration internally;
• serve configuration files to ConfigCat SDKs;
• centralize outbound communication;
• reduce repeated external downloads;
• expose internal feature flag evaluation endpoints.

The evaluation endpoints can also help teams avoid sending the complete config.json file to frontend applications. Instead, the frontend can request evaluated values through the Proxy.

The Proxy supports horizontal scaling and external cache providers including Redis, MongoDB, and DynamoDB. It can also provide real-time feature flag change notifications through Server-Sent Events and gRPC.

ConfigCat Proxy is optional. The standard SDKs already evaluate flags locally and continue using cached configuration when refreshes fail. The Proxy adds another layer of caching, isolation, and operational control for environments that need it.

Why Recovery Without Restarts Matters

During an incident, asking customers to restart applications can be painful:

• restarts may require coordinated maintenance windows
• stateful services may require coordinated failover and careful restart sequencing
• restarting a large fleet can take time and create additional operational load during an incident

ConfigCat SDK behavior is built around continuity. If your process is running and has cached config, evaluation continues. If connectivity is interrupted, SDKs keep trying and recover in place when the path is restored.

That is a practical difference that helps reduce operational stress.

Fault Tolerance From the CDN to Application Code

ConfigCat's feature flag fault tolerance can be understood as a series of layers:

1. Static configuration is distributed through a global CDN.
2. SDKs store the latest valid configuration locally.
3. Flag evaluation happens inside the application.
4. Persistent or shared caches can protect frequently restarted workloads.
5. ConfigCat Proxy can provide an internal caching and delivery layer.
6. Application-defined defaults cover cases where no valid configuration is available.

Each layer addresses a different failure scenario. Together, they help turn a temporary delivery problem into delayed configuration updates rather than an application outage.

How to Test Feature Flag Failure Scenarios

Fault tolerance should not exist only in an architecture diagram. You should test it in an environment that resembles your production setup.

A basic resilience test can follow this sequence:

1. Start the application with normal access to ConfigCat.
2. Confirm that the SDK downloads configuration and evaluates a flag.
3. Interrupt access to the ConfigCat configuration endpoint.
4. Evaluate the same flag again and confirm that the cached configuration is used.
5. Change the flag in the ConfigCat Dashboard while connectivity is unavailable.
6. Restore connectivity.
7. Confirm that the SDK retrieves the updated configuration without restarting the application.
8. Repeat the test with an empty cache to verify that your application-defined default values produce safe behavior.

Test the lifecycle characteristics of your real workload as well. A serverless function using a persistent cache behaves differently from a continuously running service using only in-memory storage.

You should also verify what happens when:

• the application starts without network access;
• the cached configuration is older than expected;
• the shared cache becomes unavailable;
• the Proxy is reachable but the external CDN is not;
• the fallback value activates a fail-open or fail-closed path.

These tests reveal whether your fallback strategy is actually safe before an incident forces you to find out in production.

How Local Evaluation Affects Pricing

Local feature flag evaluation also influences ConfigCat's pricing model. Because feature evaluations happen locally, the recurring interaction with ConfigCat is downloading config.json files.

ConfigCat's pricing model therefore focuses on config.json downloads rather than:

• the number of individual flag evaluations;
• the number of monthly active users (MAUs) evaluated.

An application can evaluate flags repeatedly between configuration downloads without each evaluation becoming a separate ConfigCat request.

If you deploy ConfigCat Proxy, centralizing and caching downloads can reduce external download volume further while still serving many internal applications.

Open Source SDKs for Transparency

ConfigCat Dashboard and management APIs are commercial products, but the SDKs are open source. This means that your team can inspect the code running inside your applications.

Engineers can review how an SDK downloads configuration, stores cache entries, evaluates targeting rules, handles errors, and returns default values. This transparency is particularly valuable for infrastructure components that influence product behavior.

You do not have to rely only on a product description of the expected failure mode. Your engineers can inspect the implementation directly in the ConfigCat SDK repositories on GitHub.

Build Failure Behavior Into Your Feature Flag Strategy

A feature flag platform should help avoid production incidents, not create another one.

ConfigCat SDKs evaluate feature flags locally, continue using the latest valid configuration when refreshes fail, and retrieve updated configuration automatically when connectivity returns, according to the configured polling mode. If no usable configuration is available, application-defined defaults provide a final, predictable fallback.

For many long-running applications, the standard SDK configuration already provides strong protection against temporary network failures. Workloads that restart frequently or operate under stricter network requirements can add persistent caching, shared caching, offline evaluation, or ConfigCat Proxy.

Whichever setup you choose, test it deliberately. Interrupt configuration access, verify cached evaluations, start an instance with an empty cache, restore connectivity, and confirm that the SDK receives new configuration without restarting the application. That is the difference between assuming your feature flag integration is resilient and knowing how it will behave during an outage. Ready to build fault-tolerant feature flagging into your application? Explore the ConfigCat SDK documentation to choose the right polling and caching setup for your workload, or start using ConfigCat and test the failure scenarios described above in your own environment.

For more on release safety and resilient feature delivery, follow ConfigCat on LinkedIn, X, Facebook, and GitHub.