Changelog — the production deployments

One row per production deployment: when the platform published it, which branch it came from, whether the build succeeded, the deployment’s own id, and the commit behind it. It also carries the commit each deployment was built from — the subject and the short sha, both of which the deployments API has always returned and this page used to discard. Several deployments can share one commit: a deploy made from a working tree records the commit it was made from, so a repeated subject is the record being accurate rather than a fault.

The file states no window, so read the table as the deployments the platform reported when the file was written rather than as a complete history of the project. The period the rows actually cover is printed above them, computed from the oldest and newest stamps in the file itself.

Most consultancies present themselves as the finished output of completed work. This is a single-engineer operation in the middle of building, and this is the receipt: the deploy cadence is visible, by the hour, out of the host’s own log. If you are deciding whether Garnet is a live operation or a sales site with a logo, that answers it in one scroll.

Read from the Cloudflare Pages deployments API for this project, filtered to the production environment. It is not hand-maintained, so it cannot drift from what actually shipped. The figures above the table are counted from the rows themselves rather than read from a summary field, and the file’s own count is printed beside the counted total instead of replacing it — if the two ever disagree, the page says so on the page.

Open data. /assets/data/changelog.json — CC0-1.0, no auth, no rate limit.