Publishing the method before the numbers

Our transparency methodology is published. There are no reports behind it yet — not one number. That order is deliberate, and it is the only part of the plan I would defend to the point of being annoying about it.

Anyone can publish a good month

A transparency report where the publisher chose the definitions after seeing the data is a marketing asset with a table in it. The choices that determine the answer all happen before anything is measured: what counts as delivered, whether latency is a mean or a distribution, whether incident minutes start when the customer noticed or when we did, which months are excluded as unrepresentative.

Every one of those is defensible in isolation. Chosen retroactively, together, they will produce whatever number you want.

So the method goes first, in public, with a date on it. If a future report drifts from it, that drift is visible, and somebody gets to point at it.

The definitions that cost us something

Two in particular:

Latency as a distribution, never a mean alone. A mean latency looks fine while the tail is catastrophic, and the tail is the entire point — the late messages are the ones attached to a delivery window or a password reset.

Incident minutes measured from first customer impact. Not from when our monitoring fired, not from when we acknowledged it. The gap between impact and detection is the most embarrassing number an infrastructure company has, and excluding it is the most common quiet trick in status-page reporting.

What happens when it goes badly

It will. A month will come where the numbers are bad, and publishing them will cost us a deal. The commitment is only worth something because that is foreseeable and we wrote it down first.

The first report we will genuinely want to skip is the one that proves this is worth reading.