Hi Team, We have been using growthbook since quite a while now. But since 3rd August, on roughly every deployment, a small number of our Node processes complete init() with an empty feature set. Those processes then return the default value set in my codebase for every flag for the rest of their lifetime and never recover. Only restarting the process fixes it probably because init itself is failing. Environment Details: • @growthbook/growthbook 1.5.1, GrowthBookClient, Node.js • init({ streaming: true, timeout: 5000 }) // We had kept no timeout initially. Added 5s as timeout in the latest deployment. • setPolyfills({ EventSource }) using the eventsource npm package • 32 independent client instances per deploy: 8 PM2 cluster workers × 4 AWS ECS Fargate tasks. All initialise within ~3 seconds of each other during a rolling deploy. • Feature payload: 200+ features • AWS ap-south-1, egress via a single NAT gateway Evidence from our latest occurrence (2026-08-05) We instrumented init() to log its InitResponse plus getFeatures() count per worker. The rollout produced 32 records: • source: "network",

success: true

◦ count: 30 ◦ featureCount: 280, ◦ all returned in under ~2.5s • source: "timeout",

success: false

◦ count: 2, ◦ error: "Timeout" ◦ featureCount: 0 Details for failing records (UTC): 2026-08-05T122005.109Z { success: false, source: "timeout", error: "Timeout", featureCount: 0 } 2026-08-05T122006.722Z { success: false, source: "timeout", error: "Timeout", featureCount: 0 } Earlier occurrences, all coinciding with a rolling deploy: 2026-08-03T02:15Z - 1 of 4 tasks affected 2026-08-03T11:43Z - 1 of 4 tasks affected 2026-08-05T10:42Z - 3 of 4 tasks affected

Hello, Thank you for the detailed info. It seems like when

init({ timeout: 5000 })

times out, the SDK doesn't throw or retry, but simply resolves with

success: false

and leaves the client permanently in its default state. Since streaming is only wired up as part of a successful init, a process that times out never gets a live SSE connection either, so there's nothing left to self-heal it. The timeouts themselves are likely a side effect of your deploy pattern: 32 processes (8 PM2 workers × 4 Fargate tasks) all calling

init()

within a ~3 second window, all sharing one NAT gateway's egress IP. That burst of simultaneous new connections occasionally pushes a couple of requests past the 5s threshold, not because GrowthBook is unreachable, just briefly slower under that concurrent load. Before you added the timeout, those same slow requests would have taken longer to succeed rather than being abandoned. If you could try: 1. Add a background safety-net poll, even with streaming enabled — this alone prevents the "stuck forever" outcome:

setInterval(() => gbClient.refreshFeatures(), 5 * 60 * 1000);

2. Reduce concurrent connections at deploy time That should help prevent the same patterns. I hope this helps.