Paranoid about uptime? 10 things to do!

Check Statsig service uptime, view the public status page, and learn about SLAs and historical reliability for SDKs, console, and pipelines.

Statsig serves billions of individual user interactions and is designed for reliability and availability. If your application can't reach Statsig for any reason, it continues to work as expected using locally cached values.

The following best practices help maximize your uptime across issues including failed client connectivity, failed server connectivity to Statsig, and buggy or deprecated code. You can also read more about how Statsig designs for failure.

  1. Feature Gates and Experiments have default values used during evaluation. You can disable Feature Gates and set a default value; if the SDK has no information, the value defaults to false. For experiments, specify default values in code. Validate that these defaults work and don't break the experience.

  2. Test your code with all possible assignments in Experiments and Feature Gates. Use overrides and inline real-time diagnostics. Identify crashing variants before rolling out your experiment.

  3. Use Statsig's support for pre-production environments (e.g. Dev, Staging) as part of your validation process. Pre-production environments can remove change approval requirements, allowing faster iteration.

  4. Start small, validate and then ramp. With feature gates, Statsig recommends rolling out to 2% (check for crashes/obvious bugs) before ramping up to 10%, 50%, and then 100% while watching metrics. You can also have Statsig fire Rollout Alerts when thresholds are violated.

  5. Clean up your code and remove features you have finished launching. Leaving untested or unmonitored code paths increases risk because those paths can still be triggered.

  6. Use change management on Statsig in production. A reviewer should approve changes. For critical areas, you can enforce an Allowed Reviewer group that has enough context to decide. Statsig Feature Gates let you easily audit and roll back changes.

  7. Caching on client SDKs: Initializing Statsig client SDKs requires them to connect to Statsig and download config. Client SDKs can cache and reuse config (for the same user) if they are offline. You can also choose to bootstrap your client from your own server (and remove the round trip to Statsig) by using client SDK bootstrapping.

  8. Caching on server SDKs: Initializing Statsig server SDKs requires them to connect to Statsig and download config. If connectivity to Statsig fails, initialization fails (falling back to default values). Two key things can help mitigate this (and related) risks.

    1. Deploy the Statsig Forward Proxy so your servers connect to this endpoint to download config instead of connecting to Statsig directly. This also reduces network traffic and improves consistency of configuration across your server fleet.
    2. Reduce connectivity-related SDK initialization failures by providing config locally using a dataAdapter.
  9. Test for failure conditions explicitly (for example, no Statsig client or server connectivity). Run a disaster simulation such as breaking DNS routing to Statsig within your data center, and test client app behavior when Statsig is unreachable. Go to the testing guide for available capabilities.
  10. Implement a custom proxy to prevent adblockers from blocking events or initialization in client SDKs. Adblockers can interfere with Statsig's default endpoints, preventing your application from logging events or initializing properly. By setting up a custom proxy on your own domain with custom endpoint names, you ensure that tracking blockers don't intercept your API calls and that you capture all necessary data.

Was this helpful?