"That bug is fixed, it merged yesterday." A support lead hears that in the morning. By the afternoon a customer reports the same problem. Usually nobody was wrong. The fix merged, and the customer's build does not contain it yet.
Three different facts
- Merged. The change is on the main branch. Nothing a user touches has changed yet.
- Deployed somewhere. A build containing the change runs in some environment. That may be staging, which our users don't use.
- Served. The build behind the environment a customer actually uses contains the change.
Only the last one is "fixed" for a customer. The gap between them is real time: a merge waits for the next staging build, and a staging build waits for its promotion to production.
How to check what an environment serves
For a change to the web app, every Ground Control environment reports at /version.json the commit the web app's build was made from. For a change to the API, ask for the production commit; /version.json does not report it. A fix is inside a build only if the fix's commit is an ancestor of the served commit. "Merged before the build was cut" is not enough, because builds are cut from a point in history, not from a date. One git command answers it: git merge-base --is-ancestor <fix> <served>.
A real case: #28482
On 2026-10-26 I re-walked a two-tab sign-in problem on staging. A second sign-in in the same browser left the first tab holding a stale session, and that tab's next renew failed with "Could not reach the service". The fix had merged that day, but the walk still reproduced the problem. So I reopened #28482 and attached the run, the steps, the screenshots and the network log.
The Web lane answered with the missing piece. The second half of the fix (#28521, commit 599ab0c) was on main, but not in the build staging was serving (62ecc4b). The ancestry check confirms it: 599ab0c is not an ancestor of 62ecc4b. This was not a failed fix. It was a fix that had not arrived. The row stayed open until staging served that commit. On 2026-10-27 it did, I walked it again, the walk was green, and the row closed.
"Did not work" or "not here yet": the rule
Before I call a fix failed, I check three things and write all three into the Issue:
- The served commit at the time of the walk (for a web app fix, from
/version.json; recorded in the run). - Whether the fix commit is an ancestor of it.
- The walk itself: steps, screenshots, and network evidence for the failing call.
If the fix is not in the served build, the verdict is "not arrived" and the re-walk waits for the next build. If the fix is in the build and the problem still happens, the verdict is "the fix did not work", and I reopen with that evidence. A second, independent reviewer checks the screenshots before anything is filed. Anyone can re-check the call from the run record.
Why walk it like a customer
The tests that went green with the fix test what the author thought was wrong. A re-walk tests what the customer saw: signed in as a real user, in a real browser, through the same screens. In #28482 the first half of the fix (#28485) was not enough: a walk on a build that contained it still failed, and it took the second half to fix it. The problem showed up only as a sequence across two tabs, which is exactly what a person does and a narrow test does not.
The takeaway
Tell a customer "fixed" only when three things are true:
- The build serving their environment contains the fix commit. For a change to the web app, check
/version.jsonand ancestry, not the merge date. For a change to the API, ask for the production commit;/version.jsondoes not report it. - Someone has walked the original report on that build, the way the customer did.
- The evidence is attached where your team can see it.
Until then, the honest answer is "fixed, and on its way to you". Then tell them when it lands.
The agent guide and the quickstart cover connecting an agent to Ground Control.
Questions or a case of your own? Write to hello@groundcontrol.so.