Log monitoring script scans full log history instead of current run — causes persistent false alarm notifications

Resolved 💬 2 comments Opened Apr 10, 2026 by ChromawaveLLC Closed May 23, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

When generating a shell script to monitor an append-only log file for errors on a scheduled basis, the AI used full-file grep against the entire log rather than scoping the search to the most recent completed run. This causes every previously-resolved error in the log history to re-trigger alert notifications on every subsequent check — indefinitely.

A secondary issue: the script flagged low-resolution video downloads as a potential error condition. For media archival tools like yt-dlp, low resolution is a valid outcome for SD-era content — the tool always fetches the best available quality. Flagging it as an error produces false positives for legitimate downloads.

What Should Happen?

When generating log monitoring or alerting scripts for append-only logs with run markers, the AI should default to extracting only the most recent completed run before scanning:

Extract only the most recent run between start/end markers

RECENT=$(awk '/=== run started at /{buf=""} {buf=buf"\n"$0} END{print buf}' "$LOG")

Skip if the run hasn't finished yet

if ! echo "$RECENT" | grep -q "Run finished"; then
echo "Most recent run has not completed — skipping."
exit 0
fi

Scan only the current run

BOT=$(echo "$RECENT" | grep -cE "Sign in to confirm you" || true)
RATE=$(echo "$RECENT" | grep -cE "HTTP Error 429" || true)
Low-resolution outcomes should not be classified as errors. Quality-level results from yt-dlp (240p, 360p) are successful downloads, not failures.

Error Messages/Logs

Error Messages / Logs

No error message is produced — the script exits 1 silently, which causes the task scheduler (Synology DSM) to send an alert email. The email subject reads:


ALERT: Issues detected in most recent ytdl-sub run
- BOT DETECTION: 3 occurrence(s)
- RATE LIMITED (429): 1 occurrence(s)
These counts reflect occurrences across the entire log history, not the current run. The actual current run completed cleanly.

Steps to Reproduce

1: Ask Claude to generate a shell script that monitors a yt-dlp/ytdl-sub log file for error patterns and sends a notification on failure
2: Run the generated script after multiple download runs have accumulated in the log
3: Introduce and then resolve an error condition (e.g., bot detection) in an earlier run
4: Run the script again on a later, clean run
5: Observe: the script still reports the previously-resolved error as a current issue

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

N/A Unknown — no prior version to compare against. This was the initial generation.

Claude Code Version

Claude Code for VS Code 2.1.98

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

VS Code integrated terminal

Additional Information

This pattern is likely to affect any user who asks Claude to generate scheduled monitoring scripts for append-only log files — a common pattern in server automation, Docker container monitoring, cron-based alerting, and NAS task schedulers. The fix is straightforward (scope to the most recent run using the log's own delimiter markers) but requires the AI to recognize that a scheduled script running against a growing log needs run-scoped parsing by default, not whole-file grep.

The alert fatigue impact is significant: users receive daily false alarm emails for issues that resolved days ago, eroding trust in the monitoring system.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗