A cron redirect killed this watchdog before sudo ever ran

Redirections belong to the shell, not to the command. The shell that launches a cron line opens them first and then execs the command, and cron ran this line as the waha user ^[12]. So `>> /opt/waha-watch/cron.log` was opened with waha's permissions before sudo was involved at all ^[12]. The directory is root:root, mode 755, and cron.log did not exist yet ^[13]. waha cannot create a file there, so the redirection failed and the shell exited before it reached sudo ^[13][14]. The command never ran ^[14]. "The privilege you granted the command is irrelevant when the shell dies setting up its plumbing first," the author wrote in the dev.to post ^[15].

A `*/10` schedule is six runs an hour ^[8]. Over five days that is 720 attempts, and each one put a permission error on the cron shell's stderr ^[16][11]. cron handled that the way it always does: it tried to mail the output to the user, found no mail server, and threw the text away ^[11]. The syslog entry for the job sits next to "(CRON) info (No MTA installed, discarding output)" ^[10].

watch.log fills up whenever the tool runs, from cron or from a terminal ^[8]. The five entries that made everything look fine were stamped 21:40:12, 21:52:03, 21:59:47, 22:22:15 and 22:32:51 on 2026-09-08, all inside a 53-minute window on one evening ^[7][17]. A ten-minute schedule fires on the round ten, so :52 and :59 cannot come from it ^[8]. Every one of those lines was the author running the tool by hand on install day ^[8]. "Manual runs and cron runs land in the same file and look identical unless you read the clock," he wrote ^[9].

Two checks separate the script from the schedule, and both sit outside the tool. The first is the file the shell was supposed to open: cron.log stayed empty for five days while `crontab -l -u waha` printed the line exactly as installed ^[4][6]. The second is the clock. By the day the production line went dark, the newest entry in watch.log was five days old ^[18]. The post calls the MTA message one of the highest-signal lines in all of syslog and notes that almost nobody greps for it ^[19].

This failure needs three things at once: the redirect target must sit somewhere the job's user cannot write, the host must have no MTA to deliver the complaint, and the tool must keep its own log, whose recent lines make the job look healthy ^[13][11][8]. Remove any one and the problem surfaces in hours. With mail configured, 720 permission-denied messages would have landed in waha's mailbox over those five days ^[16]. This is one engineer's account of one host, and 720 is arithmetic on the schedule, with no observed log lines behind it ^[16].