Skip to main content
GrowthBook logo

Is GrowthBook Down?

No — GrowthBook is up

Reachable from all 8 checked regions

Average response time: 282ms

Last checked · checks run every 6 hours

Official status page: https://status.growthbook.io

GrowthBook uptime

100%
Last 7 days
100%
Last 30 days
100%
Last 90 days
142ms
Avg response, 30 days

Measured from multiple regions every 6 hours. Percentages count only checks that returned an availability answer — 13 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

30-day history

13-day clean streak
Aug 22: no data
Aug 23: no data
Aug 24: no data
Aug 25: no data
Aug 26: no data
Aug 27: no data
Aug 28: no data
Aug 29: no data
Aug 30: no data
Aug 31: no data
Sep 1: no data
Sep 2: no data
Sep 3: no data
Sep 4: no data
Sep 5: no data
Sep 6: no data
Sep 7: no data
Sep 8: 100.00% uptime, 16 checks
Sep 9: 100.00% uptime, 29 checks
Sep 10: 100.00% uptime, 32 checks
Sep 11: 100.00% uptime, 32 checks
Sep 12: 100.00% uptime, 31 checks
Sep 13: 100.00% uptime, 24 checks
Sep 14: 100.00% uptime, 32 checks
Sep 15: 100.00% uptime, 32 checks
Sep 16: 100.00% uptime, 31 checks
Sep 17: 100.00% uptime, 32 checks
Sep 18: 100.00% uptime, 32 checks
Sep 19: 100.00% uptime, 32 checks
Sep 20: 100.00% uptime, 16 checks
Aug 22 Today
No downtime Partial Downtime Not measurable No data

Reachability by region

Each region runs its own request from a different part of the world. A service can be up for one continent and down for another, which is usually the first sign of a routing or CDN problem.

ams
223ms
DNS 164ms TCP 2ms TLS 10ms TTFB 215ms
arn
187ms
DNS 143ms TCP 1ms TLS 8ms TTFB 180ms
nrt
219ms
DNS 177ms TCP 1ms TLS 10ms TTFB 214ms
ord
242ms
DNS 193ms TCP 2ms TLS 10ms TTFB 233ms
sin
304ms
DNS 246ms TCP 1ms TLS 14ms TTFB 296ms
sjc
419ms
DNS 192ms TCP 34ms TLS 40ms TTFB 324ms
syd
346ms
DNS 297ms TCP 2ms TLS 14ms TTFB 339ms
yyz
321ms
DNS 274ms TCP 1ms TLS 8ms TTFB 314ms

What GrowthBook does

GrowthBook is an open-source feature flagging and experimentation platform. Applications fetch flag definitions from its CDN and evaluate them locally, then send experiment exposure data back for analysis against a warehouse the team already runs. It is offered both as GrowthBook Cloud and as software teams host themselves, so two customers can depend on very different infrastructure under the same name.

What an outage looks like

Feature flags stop updating and applications keep serving whatever values they last fetched, so a rollout freezes rather than failing loudly. Changes saved in the GrowthBook interface do not reach running services. If the SDK cannot reach the CDN at startup it falls back to the defaults compiled into your code, which can quietly turn a live feature off for new instances.

What to do about it

Read status.growthbook.io, which reports GrowthBook Cloud App, Api and CDN as three components with 90 days of uptime each. If CDN is the affected row, running applications are still serving cached flag values and the risk is stale configuration, not an error. Confirm your SDK has a sensible fallback for a failed fetch before changing anything, and hold flag changes until the CDN row recovers so you are not reasoning about a rollout you cannot deliver.

Is it down for everyone, or just you?

If this page says GrowthBook is up but it is not loading for you, the problem is between you and them. Run a check against any URL from up to 18 cities across three regions to find out where it breaks.

Test it yourself

Related services

GrowthBook outage FAQ

I self-host GrowthBook. Does the status page apply to me?
No. status.growthbook.io reports GrowthBook Cloud App, Api and CDN, which are the hosted service. A self-hosted deployment runs on your own infrastructure and database, so an incident there says nothing about your instance and an all-clear does not clear you either. Check your own containers, MongoDB and the CDN or proxy you serve flag payloads from before looking at GrowthBook's page.
My flags are not updating but the app is fine. Is GrowthBook down?
That is the usual shape of a CDN incident. GrowthBook SDKs fetch flag definitions and evaluate them locally, so an application keeps running on the last payload it received and nothing errors. The symptom is a rollout that will not move rather than a failure. Check the CDN row on status.growthbook.io before debugging your own targeting rules.
What happens to my A/B test data during a GrowthBook outage?
Experiment analysis reads from your own data warehouse rather than from GrowthBook's storage, so historical results are held where you keep your event data. What an outage interrupts is the interface for querying and displaying them. GrowthBook does not publish a guarantee covering exposure events sent during an incident, so confirm the affected window against your warehouse rather than assuming completeness.
Can a GrowthBook outage break my application?
It can change behaviour rather than break it. If the SDK cannot fetch a payload it uses the fallback value in your code, so a newly started instance may serve defaults while older instances keep the flags they already have. That split is the risk worth planning for: set deliberate fallbacks and cache payloads locally so an unreachable CDN produces a known state instead of an accidental one.
Is GrowthBook down or is it my SDK integration?
Compare scope. An integration fault affects one application or one SDK version and usually shows an error in your own logs, while a GrowthBook incident stops flag updates for every consumer at once. status.growthbook.io publishes per-component uptime graphs, so a dip on CDN or Api confirms the platform side. Fetching the flag payload URL directly is the fastest local check.

How we measure this

  • We request GrowthBook's public endpoint every 6 hours from Fly.io regions across six continents — the most recent check ran from 8 of them.
  • A region counts as down only when it gets no usable HTTP response. A 403 or 429 means the origin answered and refused us, which we report as blocked, never as an outage.
  • A single failing region is treated as probe noise. We only change the verdict when two consecutive cycles agree.
  • Response times average only the regions that actually served the page, so a timeout never inflates the number.
  • Where GrowthBook publishes an official status feed we read it too. An all-clear from the vendor can soften an unconfirmed degradation; a vendor-declared outage only worsens our verdict when our own checks corroborate it.

Get alerted when GrowthBook goes down

This page refreshes every 6 hours. Your own monitors run as often as every 30 seconds, from up to 18 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required