Every deploy, in order.

Scroll the table sideways for the digest column.

What the digest column is for

The digest is a SHA-256 taken over every file in the built site. Two rows carrying the same digest shipped identical bytes, however different their deployment identifiers look. A version identifies an event. A digest identifies what was in it.

In this record no digest repeats. Every deploy changed something. That is worth knowing in both directions: no build was a no-op, and there is no row to point at and say the site was reshipped unchanged.

The marked row

The first line carries unknown where a deployment identifier belongs. The deploy happened; the script was not yet capturing what Cloudflare returned. It is left in and marked rather than filled in afterward from memory. A record you may edit later is not a record.

The last row is always missing, and it cannot be otherwise

This page was built from 49 rows. The deploy that published the copy you are reading is row 50, and it is not on the page.

That is the order the work happens in and not an oversight. The site is built, the build is gated, the result is deployed, and only then is the row written — because the deployment identifier and the digest do not exist until the deploy has happened. Rendering the row first would mean writing down a fingerprint of something that had not shipped yet.

So the record trails reality by exactly one deploy, permanently. It is said here rather than left for a reader to notice that the newest deploy is never the newest row.

Why the type is this small

It is evidence, not argument. Nobody is expected to read every row and the page is not asking anyone to. The point is that every row is there to be read, that the list is complete from the day it starts, and that its gap is declared instead of closed. Set at reading size this would look like a brochure about diligence. At this size it looks like what it is.