2026-08-28 — analytics.minRequestStatus defaults to 500

cloudflareDefaults.analytics.minRequestStatus moves from 0 to 500. A data point is now a failure unless a Worker says otherwise.

This reverses the decision recorded on 2026-08-08, and that entry's reasoning is worth restating before the reversal, because it was not wrong:

The trade-off belongs to the deployment, not to this package, which is why the default does not change: a dataset holding only failures cannot answer request rate or latency percentiles, because the denominator is not in it.

Every clause of that is still true. What it assumed is that deployments would exercise the choice.

What consumers actually did with it

Twenty days later, of the eight Workers binding a TELEMETRY dataset, two had set the threshold — the same two whose forks motivated the setting in the first place. The other six had not.

Those five were not a decision. They were the absence of one, and the absence read as "record every 200", which is the expensive answer and the one that buries what anyone queries the dataset for.

Only one had actually chosen it, and it had recorded that choice the only way the old default allowed — as a sentence in a comment saying the field was deliberately left alone. A default nobody can see they are accepting is not a default anyone has agreed to.

What changed

Nothing else moved. AnalyticsService.request still applies the same status >= minRequestStatus check, event() is still unaffected because a domain metric does not describe a response, and the setting still accepts any value.

The documentation on AnalyticsSettings.minRequestStatus was rewritten around the new default, and now names 400 and 0 as the two reasons to move off it rather than presenting 0 as the baseline.

Consumers

• The two already at 400 — moved to 500. Both are reached over service bindings and neither watches client errors; the 400 predated a default that made a choice at all.
• The one recording everything on purpose — now pins minRequestStatus: 0 explicitly. Its intent had been expressed by not setting the field, which the new default would have silently reversed. This is the change that matters most in this entry: the same behaviour, now written down where the code can be read instead of inferred from a default it happens to agree with.

Anything else consuming this package on upgrade stops recording 2xx and 4xx without a code change. That is the intent, and it is still a behaviour change arriving through a version bump — a deployment that queries request rate from Analytics Engine needs minRequestStatus: 0 before upgrading, not after noticing.

Tests

109 specs across nine suites, up from 105. The default-threshold block in test/core/services/AnalyticsService.spec.ts was rewritten rather than deleted — it now asserts that a 200 and a 404 are skipped and a 500 is recorded — and a new block covers minRequestStatus: 0, which previously had no coverage because it was the default.

One case needed a real fix rather than an inversion. drops the point when the dataset is unbound passed a 200, and under the new default it would have returned false because the threshold filtered it, never reaching the unbound- binding path it exists to cover. It now passes a 500. A test that passes for the wrong reason is worse than one that fails, and moving a default is exactly the kind of change that exposes them.

test/middlewares/logger.spec.ts gained the same split: no metric for /ok, none for /missing, one for /broken.