Skip to main content
Flagsmith logo

Is Flagsmith Down?

No — Flagsmith is up
Flagsmith's status page
Operational · no open incidents
FlareWarden checks
Website reachable · 8 of 8 regions · 368 ms

Right now

The verdict is the worse of these two. How we decide

Flagsmith's status page

status.flagsmith.com · read · checked every 3 minutes

Operational
Flagsmith's components, as its status page reports them
ComponentStatus
Edge APIOperational
Admin APIOperational
Admin DashboardOperational
Public WebsiteOperational
[DEPRECATED] SDK APIOperational

FlareWarden checks

app.flagsmith.com from 8 regions · when you open this page (at most every 30 minutes), otherwise every 6 hours

Reachable
Regions up
8 of 8
Response
368 ms
Checked

By region

  • Ashburn reachable, 391 ms
  • Chicago reachable, 284 ms
  • Frankfurt reachable, 130 ms
  • Johannesburg reachable, 525 ms
  • London reachable, 91 ms
  • Los Angeles reachable, 251 ms
  • São Paulo reachable, 415 ms
  • Tokyo reachable, 864 ms
Timing by region
Connection timing for each region that loaded the page
RegionDNSTCPTLSTTFB
Ashburn224 ms2 ms10 ms390 ms
Chicago111 ms1 ms24 ms284 ms
Frankfurt34 ms2 ms13 ms130 ms
Johannesburg230 ms1 ms79 ms525 ms
London47 ms2 ms8 ms91 ms
Los Angeles31 ms2 ms36 ms248 ms
São Paulo165 ms1 ms9 ms414 ms
Tokyo268 ms1 ms127 ms863 ms
We check that app.flagsmith.com loads, not every feature behind it. Test it yourself

History

Incidents Flagsmith reported

Since Oct 22, 16 days · from status.flagsmith.com

Incidents
1
Major or critical
1
Median to resolve
15m
  1. Admin and SDK API outage

    critical ·

    lasted 15m

Flagsmith website availability

Measured by FlareWarden · app.flagsmith.com

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

Last 30 days

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

Measured by FlareWarden's own checks of app.flagsmith.com from multiple regions every 6 hours. Flagsmith's status page sets the verdict above when it reports trouble, but never these figures. Percentages count only checks that returned an availability answer — 72 days measured so far. A dash means that window does not yet hold enough measured days to publish a figure.

What Flagsmith does

Flagsmith is a feature flag and remote configuration service. Teams define flags in a dashboard and applications read them through SDKs, either by calling Flagsmith's Edge API or by evaluating a downloaded environment document locally. It is open source and can be self-hosted, so the hosted platform is one deployment option among several rather than the only way to run it.

What an outage looks like

The dashboard at app.flagsmith.com fails to load, or flag changes save but never take effect in running applications. The applications themselves often keep working, because SDKs in local evaluation mode serve flags from the environment document they last downloaded. Services that restart or scale up mid-incident are the ones at risk, since they start with nothing cached and fall back to code defaults.

What to do about it

Check status.flagsmith.com, which separates Edge API, Admin API, Admin Dashboard and Public Website. An Admin Dashboard incident does not stop flag evaluation; an Edge API incident does. Hold deploys and avoid autoscaling events while it is unresolved, since new instances start without a cached environment document. Self-hosted installations are unaffected by an incident on the hosted platform.

Is it down for everyone, or just you?

If this page says Flagsmith 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 17 cities across three regions to find out where it breaks.

Test it yourself

Related services

Flagsmith outage FAQ

Does my application break when Flagsmith is down?
Often not. Flagsmith SDKs support local evaluation, where the SDK periodically fetches an environment document and evaluates flags in process instead of calling the API on every request. Applications running that way keep serving the flag values they already hold. SDKs that call the Edge API per evaluation are the ones that feel an outage immediately.
Which component matters for my application?
The Edge API. Flagsmith reports Edge API, Admin API, Admin Dashboard and Public Website as separate components, and only the Edge API sits in your application's request path. The Admin Dashboard failing is an inconvenience for whoever wanted to flip a flag. The Edge API failing is what reaches your users.
Will a flag change I make now reach production?
Not until SDKs can fetch again. A change saved in the dashboard has to travel to running applications through an environment document refresh, and during an Edge API incident those refreshes fail. Applications hold their previous values until one succeeds, which means an emergency kill switch may not fire at the moment you most need it.
Does this affect self-hosted Flagsmith?
No. Flagsmith is open source and documented for self-hosting, and an installation running in your own infrastructure does not depend on Flagsmith's hosted platform being reachable. The measurement on this page covers the hosted service, so an incident here is not evidence about your own deployment.

How we measure this

  • We request Flagsmith's public endpoint every 6 hours from Fly.io regions across six continents — the most recent check ran from 8 of them. When you open this page and our last check is more than 30 minutes old, we check again on the spot; those checks update the verdict, never the availability figures.
  • 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. Our checks only change their 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 Flagsmith publishes an official status feed we read it too, and the verdict is the worse of what it reports and what our checks see: a major outage of Flagsmith itself is Down, trouble with one part of it is Degraded, problems at a few of a provider's many locations change nothing, and a security notice that marks nothing down is shown but changes nothing either. We check the feed every 3 minutes and read it again within minutes of any change to its incidents or components; a reading counts for 45 minutes after the last check that found nothing changed. The availability figures above are our measurement alone.

Get alerted when Flagsmith goes down

We check Flagsmith every 6 hours, and again when you open this page if that was more than 30 minutes ago. Your own monitors run as often as every 30 seconds, from up to 17 cities across three regions, and tell you the moment something breaks.

Start Free Monitoring
Free plan available No credit card required