Two writes happen at the end of that run, and only one of them reaches a reader who can act on it.
On a scheduled job, stdout lands in a log file that a human opens after they already suspect something is wrong; the author puts its median readership at zero [9]. The status post goes to the surface every other component polls to work out what is still outstanding [10]. So the accurate sentence went to the archive and the false one went to the schedulers, and the component whose entire job is tracking which promises are still open recorded a clean, closed, successful run [11].
Errexit does not save you here, and it is worth being precise about why. `push_heal "$REPO" || echo ...` is a single compound command whose exit status is the status of the `echo`, and `echo` succeeds. Nothing has failed as far as the shell is concerned, so control walks the twelve lines down to the unconditional post [4]. Compare the shape the old comment describes: a pipe into `tail -1` handed git's status to `tail`, which exits zero after faithfully printing whatever git shouted on the way down [5][6]. These are two different ways to destroy the signal, but both share the same missing consumer. Writing the postmortem into a comment above the call site turns out not to be the same as wiring it into the run.
The arithmetic on the failure count deserves a caveat that the author supplies himself. Spread over 39 days, 1228 attempts is about 31 a day, roughly one every 46 minutes [1]. That describes the cadence of the repair loop's timer, not the volume of stranded work, which is why he calls 1228 the number he was handed and the wrong one [14]. The two figures that carry the outage are zero successful pushes and 39 days [13][12].
Whether the 39 days transfers to your system depends on one property: that your success string is consumed by machines while your log is consumed by nobody. If a person reads every run of the job, the stdout warning is a genuine control and this is a noisy Tuesday. If the log is only opened during an investigation, then the detection you paid for exists solely after the investigation starts.
The underlying cause is dull, which is the point. An https remote with no credential helper and no stored credentials means git asks for a username on a box with nobody at the keyboard, and it asked 1228 times starting 2026-07-21T20:48:03Z [12]. The fix behind that unread line would have taken ten minutes.
In my context I would make two changes and neither is to the wording. Gate the post on the return code, and give the failure post the same reach as the success post, because a failure that appears only on stdout does not exist until someone goes looking for it. The author's test is the cheapest audit I have seen for this class: ask what a success string is keyed on, and if the answer is that control reached this line, then it never had a real condition behind it [16]. The same wiring shows up as a CI step that logs a failed artifact upload and exits 0, a migration that prints a stack trace and returns 200 with a status of ok, and a worker that logs an exception beautifully in the catch block and marks the job complete [15].
