Engineering

Brownout

A fallback is code that only runs when something is broken, which makes it the least-tested code in any codebase. So this platform does two things about it. Every response says where its data came from and how fresh it is, in a header you can read. And every fallback below has been executed for real, with the provider it protects against genuinely refusing, inside the same request path a user hits. The receipts are underneath. Read the reference for the header grammar and how to run a probe yourself.

Proven fallbacks

Each card names an upstream, the failure injected into it, and what the endpoint did anyway. A verdict of not exercised is reported as plainly as a failure: it means the fault was accepted but a warm cache answered before any upstream call happened, so nothing was actually proven. A proof that did not run is not a pass.

Loading the degradation registry.

Reading a response

Every endpoint answers with x-brownout, and adds x-brownout-trace when something degraded. Freshness is a lattice rather than a flag, and a response reports the worst tier that contributed to it: live came off the wire during your request, cache is a hit inside its intended lifetime, stale is older than that because an upstream could not answer, and fallback means a different provider or a different method answered the question. A page assembled from one live read and one half-hour-old reading is not live, so it does not get to say it is.

The @axis/brownout package parses these headers, and gives your own tests the same fault injection this page is built on, so you can assert that your integration degrades the way you think it does.

Brownout reference Registry as JSON Repository guards Start here