One run took 59 ms. The log said success.

Nine silent failures, under 438 executions of my trading-ops automation from 15 to 25 August. Every one of the 438 logged as success with zero errors.

One of the nine finished in 59 milliseconds, was logged as a success, and had sent nothing. Every other run of that workflow took 13 to 50 seconds.

From the log, all nine looked fine. A digest run whose build step returned an empty list, so nothing was sent. Seven digests carrying 23 pending actions and no buttons to act on them. About 97 runs of a watch workflow missing from the log across two trading days, while the log showed nothing wrong.

The check that passed was the one the log runs: did the workflow finish without an error. All 438 did. What was still wrong sat underneath it, in whether the thing the workflow exists to do had actually happened. Nothing had crashed, so nothing had been reported.

My reading of the findings is that each one surfaced only when a run was set against something outside it: the workflow's own past durations, the timestamps in the state table, the message that was actually built, the gaps in the run sequence.

Limits. One system, eleven days from 15 to 25 August. The four comparisons are how I read the findings, not a documented method. A failure that none of them would expose still reads as a clean success, and I have no count of those.

What would your monitoring page show for a run that finished green in 59 milliseconds and did nothing?

Where the numbers live

One system, 15 to 25 August 2026. Counts and method only; no positions or amounts.