check_debuglog and rotate_debuglog are separate calls, in that order, in both check sequences:
check_debuglog # v2.7.0: Check 13 - debug.log watchdog
rotate_debuglog # v2.7.0: safe auto-rotation (default ON)
check_debuglog measures the file, appends its line to DETAILS, and increments WARNINGS when the size is at or above DEBUG_LOG_WARN_MB. Only afterwards does rotate_debuglog copy the file to debug.log.1 and truncate the live one to zero.
The summary card is assembled from DETAILS once all checks finish. So on any pass that rotates, the card reports the size the file had before the rotation that the same run performed.
Seen in the wild
Reported by Aussie Epic on 2026-07-26, on a testnet oracle carrying a 9 GB debug.log left over from before he installed the monitor. One --summary run produced, in order:
⚠️ debug.log Growing Large - debug.log is 8986MB🔄 debug.log Rotated - reached 8986MB, newest history preserved in debug.log.1Health Summary — ⚠️ 1 Warning, containing ⚠️ debug.log: 8986MB — debug: digidollar, net (LARGE)
The debug.log.1 mtime confirms the rotation completed during that run. By the time the third card rendered, the file it describes was empty.
The card is therefore headlined 1 Warning for a condition the same run had already resolved, sitting directly beneath a card announcing it resolved it. The obvious operator reading is "did the rotation fail?"
Why it is normally invisible
A 2 GB copy finishes fast enough that all three cards land on the same timestamp and the ordering never shows. His 9 GB copy took long enough to open a full minute between the warning and the rotation card, which made the staleness legible.
Severity
Cosmetic. It self-corrects on the next pass five minutes later, which reports the truncated size and fires the green ✅ debug.log Back Under Threshold recovery. Nothing is lost, no alert is missed, and rotation itself is working exactly as designed.
Worth fixing anyway, because Check 13 is the only self-invalidating line on the card. Every other check observes something it does not change. This one measures a file and then mutates that exact file, so it is the only place a stale snapshot can contradict another card from the same run.
Proposed fix: amend, do not reorder
Have check_debuglog stash the exact line it appended, then have rotate_debuglog substitute it on success with something describing the end state:
✅ debug.log: 1MB (rotated this pass from 8986MB)
Not reordering the two calls. check_debuglog samples the size for the growth-rate tracking (+11.4 MB/day), and rotating first would feed that a just-truncated file. That is a separate change needing its own care.
Open question
Should WARNINGS decrement when the amended line goes green?
If it does not, the headline still reads 1 Warning for a resolved condition, which is most of the confusion this issue is about. If it does, the decrement has to be targeted rather than a reset, since other checks may have incremented the same counter in the same run.
I lean yes. The card should describe the state at the end of the run, not partway through it.
Related, and worth fixing in the same change
Check 13 measures only the live debug.log, never the rotated generations beside it. On another operator's box the card reads a healthy green debug.log: 17MB while roughly 6 GB of .2 through .5 sit in the same directory. Only the Low Disk line would ever notice.
Same function, same display line, same harness. Splitting them means touching check_debuglog twice.
Target
Bundle both into the next minor release rather than shipping a patch. v2.10.0 is clean, and this behaviour has been present since v2.7.0 introduced auto-rotation.
check_debuglogandrotate_debuglogare separate calls, in that order, in both check sequences:check_debuglogmeasures the file, appends its line toDETAILS, and incrementsWARNINGSwhen the size is at or aboveDEBUG_LOG_WARN_MB. Only afterwards doesrotate_debuglogcopy the file todebug.log.1and truncate the live one to zero.The summary card is assembled from
DETAILSonce all checks finish. So on any pass that rotates, the card reports the size the file had before the rotation that the same run performed.Seen in the wild
Reported by Aussie Epic on 2026-07-26, on a testnet oracle carrying a 9 GB
debug.logleft over from before he installed the monitor. One--summaryrun produced, in order:⚠️ debug.log Growing Large- debug.log is 8986MB🔄 debug.log Rotated- reached 8986MB, newest history preserved indebug.log.1Health Summary — ⚠️ 1 Warning, containing⚠️ debug.log: 8986MB — debug: digidollar, net (LARGE)The
debug.log.1mtime confirms the rotation completed during that run. By the time the third card rendered, the file it describes was empty.The card is therefore headlined
1 Warningfor a condition the same run had already resolved, sitting directly beneath a card announcing it resolved it. The obvious operator reading is "did the rotation fail?"Why it is normally invisible
A 2 GB copy finishes fast enough that all three cards land on the same timestamp and the ordering never shows. His 9 GB copy took long enough to open a full minute between the warning and the rotation card, which made the staleness legible.
Severity
Cosmetic. It self-corrects on the next pass five minutes later, which reports the truncated size and fires the green
✅ debug.log Back Under Thresholdrecovery. Nothing is lost, no alert is missed, and rotation itself is working exactly as designed.Worth fixing anyway, because Check 13 is the only self-invalidating line on the card. Every other check observes something it does not change. This one measures a file and then mutates that exact file, so it is the only place a stale snapshot can contradict another card from the same run.
Proposed fix: amend, do not reorder
Have
check_debuglogstash the exact line it appended, then haverotate_debuglogsubstitute it on success with something describing the end state:Not reordering the two calls.
check_debuglogsamples the size for the growth-rate tracking (+11.4 MB/day), and rotating first would feed that a just-truncated file. That is a separate change needing its own care.Open question
Should
WARNINGSdecrement when the amended line goes green?If it does not, the headline still reads
1 Warningfor a resolved condition, which is most of the confusion this issue is about. If it does, the decrement has to be targeted rather than a reset, since other checks may have incremented the same counter in the same run.I lean yes. The card should describe the state at the end of the run, not partway through it.
Related, and worth fixing in the same change
Check 13 measures only the live
debug.log, never the rotated generations beside it. On another operator's box the card reads a healthy greendebug.log: 17MBwhile roughly 6 GB of.2through.5sit in the same directory. Only the Low Disk line would ever notice.Same function, same display line, same harness. Splitting them means touching
check_debuglogtwice.Target
Bundle both into the next minor release rather than shipping a patch. v2.10.0 is clean, and this behaviour has been present since v2.7.0 introduced auto-rotation.