Which commit is live right now

The question you cannot answer at the worst moment

Something is wrong on the site. The first useful question is “what changed”, and the second is “is the fix already out”. Both need one fact: which commit is serving requests, right now, on the machine the user hit.

Most small projects cannot answer it. The deploy log says a deploy finished. The dashboard says the service is healthy. Neither tells you whether the instance answering this particular request is running the build from twenty minutes ago or the one from Tuesday, and during a rolling deploy the honest answer is “both”.

The fix takes about fifteen minutes and pays for itself the first time you use it.

Stamp the build, then serve the stamp

At build time, put the facts into the artifact. In a Dockerfile:

ARG GIT_SHA
ARG BUILT_AT
ENV GIT_SHA=$GIT_SHA BUILT_AT=$BUILT_AT

Built from CI:

docker build \
  --build-arg GIT_SHA=$(git rev-parse --short HEAD) \
  --build-arg BUILT_AT=$(date -u +%FT%TZ) -t myapp:$(git rev-parse --short HEAD) .

Then expose it. One route, no authentication needed if it contains nothing secret:

GET /version
{ "sha": "a41f9c2", "built": "2026-09-02T11:04:19Z", "env": "production", "host": "web-3" }

Now “which commit is live” is a curl. Hit it repeatedly during a rolling deploy and you will watch the answer flip between two SHAs, which is the most direct demonstration of why two versions of your code run at once: the fact that makes migrations hard, three lessons from here.

Include the host or instance ID. “It works for me but not for my colleague” is very often one bad instance, and without an instance identifier in the response you cannot see it.

Tag the artifact with the commit, never with latest

myapp:latest is a moving label. Two machines pulling latest an hour apart can run different code, and a rollback to latest rolls back to nothing in particular. Tag images with the commit SHA, and let latest be an extra alias if your tooling needs one.

The same applies to a release tag. v1.4.0 is for humans; the SHA is the identity. Keep both, and make the deploy record say which SHA a version number referred to, because tags can be moved and SHAs cannot.

Tell your tools which release this is

Every observability tool has a field for the release, and almost nobody fills it in:

• Send the SHA to your error tracker as the release. It will then tell you “this error first appeared in a41f9c2”, which converts a mystery into a diff.
• Add it as a label on your metrics, but only as a low-cardinality one: a release label is fine, a per-request label is not.
• Log it once at startup, so the journal for a crashed instance says what it was running.

The payoff is a sentence you can say out loud in an incident: “errors started at 14:02, the deploy of a41f9c2 finished at 14:01, here is the diff, roll it back.”

A deploy log you can read

One append-only file or table, one line per deploy: time, SHA, who or what triggered it, and the result. Most platforms keep this for you; if yours does not, a GitHub Actions step that appends to a file is enough.

The reason to have it is that outages correlate with changes, and the changes are not only yours: a dependency updated, an environment variable edited by hand, a DNS record changed, a provider migrating your instance. A shared timeline of everything that touched production is the cheapest incident tool that exists.

Provenance, briefly and honestly

A newer layer of this is the software bill of materials (a machine-readable list of what went into a build) and signed provenance attestations proving that this artifact came from that commit through that pipeline. Tools exist and are free: Syft generates an SBOM, Cosign signs artifacts, and GitHub’s build attestations do both with a few lines in a workflow.

For a small site this is not urgent, and pretending otherwise wastes your attention. It matters when somebody else depends on your artifact, or when a compromised build server is in your threat model. Know that it exists, know the words, and reach for it when you have a reason rather than because a vendor page said supply chain.

The test

Ask somebody to run one command and tell you what is live. If they have to open a dashboard, guess from a deploy time, or SSH somewhere, this lesson is not done.