Skip to main content
Fleack sits in the network path of every API call your app makes, which means the question of what happens when Fleack itself has a problem matters. The answer is Fleack’s fail-open guarantee: no failure inside Fleack propagates to your end users as something broken in your app. This page explains what fail-open means in practice, the three failure scenarios you might encounter, and how to remove Fleack from the path entirely if you ever need to.
Fail-open is a contract, not a best-effort policy. Fleack considers a failure that breaks a user’s app to be a critical defect, equivalent to an outage. The fail-open success rate SLO is 100%.

​
What fail-open means

When Fleack encounters an internal error, it always resolves the situation in a way that your app’s existing error handling can deal with — the same way it would handle an outage or network problem on your own backend. Fleack never introduces a new failure mode that your app’s code has to learn about or handle specially. The day you remove Fleack — by pulling the CNAME — your app keeps running on your real backend without any client-side changes.

​
The three failure scenarios

​
1. Your upstream backend is unreachable

If Fleack forwards your request to your real backend and the backend does not respond — because of an outage, a network partition, or a timeout — Fleack returns a 502 with a small JSON error body. This is the same outcome your app would experience if it called your backend directly during an outage. Your existing 502 error handling kicks in. Fleack does not invent a new status code or error shape.

​
2. A test configuration is corrupt

If a test configuration stored in Fleack is malformed — for example, a variant value that cannot be serialized into the expected JSON path — Fleack skips the injection for that test entirely, forwards your backend’s response to the app as-is, and logs the error internally. Your users receive the unmodified backend response. The corrupt test is automatically flagged for review in the backoffice. No action is required on your side to keep the app functional.

​
3. The Fleack edge crashes mid-request

If the Fleack worker handling a request crashes partway through, the connection closes and your app’s HTTP client receives a server error, the same kind it would receive from any backend that crashed mid-response. Your app’s existing retry logic handles it. The next request from any user is handled by a fresh worker. The crash is isolated to that single in-flight request.

​
What Fleack never does

  • Fleack never returns a Fleack-specific HTTP status code or error body that your app would need to detect and handle specially.
  • Fleack never silently drop a request — it either forwards successfully, returns a standard error, or closes the connection cleanly.
  • Fleack never leave a user in a partially-injected state. Injection either completes fully or is skipped entirely; there is no partial rewrite.

​
Rolling back immediately

If you want to remove Fleack from the path at any point:
  1. Update the CNAME on api.your-game.com to point back to your real backend hostname, or delete the record entirely.
  2. Wait for DNS to propagate (typically under five minutes with a short TTL).
Once the CNAME is updated, your app calls your real backend directly. No code changes in the app, no app update, no coordination with Fleack required.
Set a short TTL (60–300 seconds) on your CNAME when you first configure it. This makes a rollback faster if you ever need one.