A strong answer. “The timing is the clue. A consistent interval points at something accumulating or something periodic, not at a code path — code bugs usually fail on an input rather than on a clock.

So my candidates are: a counter or buffer wrapping, a slow memory leak reaching a threshold, a periodic task colliding with another, thermal drift, or an external event on that cadence.

Method rather than debugger. I'd add minimally intrusive instrumentation — a ring buffer in RAM I can dump after the fault, or toggling a GPIO I can watch on a logic analyser, because both cost almost nothing in timing. Print-based logging over a serial line changes timing enough to hide the fault, which is why the bench never reproduces it.

Then bisect: instrument at coarse boundaries first, narrow on the next occurrence. With a four-hour period I get few attempts, so each one has to be designed rather than exploratory.

And I'd check the boring causes first — power supply ripple, a marginal connection, temperature. In my experience a meaningful share of 'intermittent firmware bugs' are electrical, and no amount of code reading finds them.”