--- title: "From 73 Percent to 11 Percent Without Touching the Deploy Tool" canonical: https://dxdev.com/everyday-ai/73-percent/ datePublished: 2026-04-23 --- **73 percent.** That was the number that stopped us, because a missing file in a five-minute update should not have had anything to do with a machine working that hard. ## A file that was there and wasn't An update was going out to a live website. The update package was opened, and a check ran right after it to make sure a particular file, `default`, had arrived. The tool reported that the package had opened successfully. On the very next line, it said the file was missing and stopped the update. The file was in the package, and the unpacking step said it had finished. Yet the next step could not see the file that was supposed to be right there. ## The old note that sent us the wrong way We had an old note that said the deployment tool was broken and that a temporary patch was already in place. It sounded useful. Instead, it sent us in the wrong direction for two whole work sessions. We treated the update process as the problem and spent most of an evening trying to work around it. That first idea did not work because it was not true. The update process was not broken. The note was stale, but it had the confidence of something we had written down for ourselves. Once we accepted it, every failure looked like more proof that the tool was to blame. The cost was time and attention, spent trying the wrong door again and again. The better question was much smaller: why would a file that had just been written not be visible a moment later? ## Two steps out of order The answer had a scary name: a **race condition**. It just means two steps that usually happen in a dependable order briefly get out of step. Usually the file is fully in place before anyone looks for it. On a bad day, the look happens during the tiny moment before it is. Here, the machine was being asked to do too much at once. The file-opening step could say it was finished before the machine had made the new file fully visible to the next check. On a calm machine, that tiny delay never showed up. We could repeat the update by hand later and everything looked normal. Under pressure, though, the check sometimes got there first and declared the file missing. ## The crowd nobody was counting The pressure came from a separate problem happening at the same time. The site had become slow because a large group of automated visitors were hitting the same page. More than 55 separate sources were involved, but each one only showed up once or twice. A simple report that lists the busiest individual visitor will not make a crowd like that stand out. It is like trying to find the cause of a packed shop by looking only for the one customer carrying the most bags. Once a traffic block was put in place, the numbers changed almost at once. The machine's workload fell from 73 percent to 11 percent. The number of active connections dropped from roughly 1,000 to 128. The site calmed down, and the updates started working again without any change to the update tool. That was the part we had missed for most of the evening. The slow site and the missing file were the same problem showing up in two places. The flood of automated visits left so little room for ordinary work that a routine file check became unreliable. ## What is fixed and what is only proposed There is a sensible improvement still to make. Between opening the update package and checking for the file, the process should pause briefly and try again a few times. That gives the machine a fair chance to finish the job before it is judged. But that improvement is still a proposal and not a completed fix. What made the updates work again that night was reducing the traffic pressure. It would be too easy to tell a cleaner story and pretend the update process had already been strengthened. It had not. We also learned not to [trust a green success message](/blog/dont-trust-the-green-deploy-grep-the-live-file/) by itself. The update tool had reported success even when the right file was not on the machine. The fix was a marker placed inside the new version of the file: present after an update, the update is real; missing, the green checkmark was only ever a claim. When a deploy reports a missing file, check the machine's load before blaming the deploy tool. Nothing about the deploy process was ever broken. The machine just never had the room to prove it.