A benchmark week produced two shipped fixes and one useful finding. It also produced four wrong conclusions, all mine, all reached confidently, all corrected before they did damage. The corrections are more instructive than the fixes, so here they are in order.
"The optimizer is wedged." A collection sat for 86 minutes reporting an activation build in flight with zero of two machines ready. I filed it as a top-priority bug. It was a healthy vamana build, progressing normally, and the worker had been logging a monotonically climbing elapsed counter the entire time -- one query away from where I was looking. Every symptom I had listed as evidence of a stall was correct behavior, including the one I found most damning: that nothing had timed out and killed it. A timeout there would have murdered a perfectly good build at minute 80.
"Two builds collided because of how we price index tiers." Wrong twice in a row. First I blamed the reference scale that build costs are quoted at. Then, having half-corrected, I proposed a fix on a code path that never consults the budget I was accusing it of misreading. Both theories died the moment I opened the dispatch site and read what it actually reserves -- one command, which I could have run before either theory.
"That build isn't comparable, it ran a different config." True, and backwards. I inferred the config from the artifact footprint and got the direction inverted. Pulling the real parameters showed the SLOWER build had the CHEAPER configuration, which meant I had not explained the anomaly away -- I had confirmed one existed.
"Cross-run build times carry 45% unexplained variance." An over-correction of the last one. Once I stopped trusting the footprint I stopped trusting everything, and threw out a contention figure that was fine. The variance was alpha, the pruning slack factor. Not unexplained at all, just not yet measured.
The through-line is not that I was sloppy -- each conclusion was a reasonable read of the evidence in front of me. It is that in every case the disambiguating measurement was already available and cheaper than the reasoning I did instead. Reading one log line, pulling one parameter blob, running one command against the dispatch path. Reasoning felt like progress and cost an hour; measuring felt like admitting I didn't know and cost a minute.
One trap deserves its own paragraph because it is environmental rather than intellectual. Two logs sit next to each other on the same machine. One is UTC and the other is local time. I built a time window from a timestamp in the first and used it to filter the second, and instead of returning nothing -- which would have told me immediately -- the window silently matched the ENTIRE second log and handed me a confident, wrong count. A filter that matches everything looks exactly like a filter that works. That one cost the most and taught the most: normalize your timestamps at the boundary, or your tooling will lie to you politely.