[ 01 ] Methodology

How this is measured

Publishing the method is the point. If you cannot reproduce a number here, it should not persuade you.

What runs, and when

Two tiers, on separate cron schedules so a tick always divides its interval — a cadence that drifts smears the hour-of-day buckets and makes a daily pattern look like a regression.

Each probe streams, runs with a 45-second timeout, and is never retried. A retry would hide exactly the transient failure this page exists to measure, so a rate limit is recorded as a rate limit rather than smoothed away.

The prompts

Verbatim. Graders are deterministic string and structure checks — there is no LLM judge anywhere in the pipeline, because a judge drifts on its own schedule and its drift is indistinguishable from the model regression we are trying to detect.

When a model is called slow, failing, dumber or rambling

These four words are the board’s labels for the one state the API calls degraded — it names whichever of the margins below was crossed, because a reader is better served by what is wrong than by which enum tripped. A model degraded for a reason with no such word reads as struggling. All of it means one thing only: the model has moved off its own trailing 7-day baseline. It never means the model is slower or worse than somebody else’s model. The JSON feed, the RSS titles and the badge SVG all still say degraded, so anything built against them keeps working.

Always against the model’s own trailing 7-day baseline, never against other models. The baseline excludes the last two hours, because a baseline that includes the incident averages the incident away — the longer an outage runs, the more normal it would otherwise look.

Entering a bad state takes two consecutive breaching windows; leaving takes three clean ones. The asymmetry is deliberate — a page that flaps is worth less than a page that is ten minutes late. The JSON feed, the RSS and the badge wait for that confirmation. The board itself does not: a model failing this window at the down threshold, or sitting at 0.00× its own normal, is named as an issue immediately, because a visitor looking at this minute should not have to wait for the next pulse to learn the model is gone. Fully offline models are also kept out of the “dumbest vs usual” callout — that line is about a model that is still answering.

Fewer than four samples in a window reads as unconfirmed in the feed, never as healthy. A newly added model has no baseline and will sit there until it has one. On the board, a model failing this window is named immediately rather than waiting for the second pulse. The tile says what it is doing.

EZO Health, and what goes into it

One number for “how is this model doing, against itself”. It is standardised so that 1.00× is exactly that model’s own normal, above is a better day than usual, and 0 is broken. That anchoring is the whole point: a model that is slow by nature scores 1.00× when it is being its usual slow self, so the score ranks how models are doing rather than how good they are. It is ours, it is not an uptime percentage, and nobody else publishes it — so here is all of it.

Four components, each anchored on a threshold above so the score can never disagree with the verdict about what counts as broken:

Combined as a geometric mean, which is what gives “0 when it is broken” its teeth: an average would let three healthy components hide one that has collapsed, and a model failing a third of its probes would still score 0.75. Multiplying means any single component reaching zero takes the score with it. The upside is capped at 1.25×, and that cap is load-bearing rather than cosmetic — the scale is asymmetric, so with a looser cap the noisiest model on the board averaged the highest health while the verdict was calling it cooked. A model with no baseline, or too few probes either side, scores nothing at all rather than scoring well.

What this does not measure

Feeds and embeds