{
  "id": 8630414,
  "title": "My Monitoring Cron Never Ran Once. crontab -l Showed It Fine.",
  "url": "https://urgent.news/2026/09/20/my-monitoring-cron-never-ran-once-crontab-l-showed-it-fine",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-20T06:49:59.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/achiya-automation/my-monitoring-cron-never-ran-once-crontab-l-showed-it-fine-27hd"
  },
  "original_language": "en",
  "account": "The monitoring tool designed to watch production systems was found to be dead for five days. The setup involved a WhatsApp automation system for businesses, where a session could silently drop, but the tool remained unaware of this issue. A dedicated watchdog named waha-session-watch was built to monitor the sessions API every ten minutes and alert if a line went quiet. It ran as an unprivileged user, waha, and required sudo for one docker call.\n\nThe crontab line for running the watchdog appeared ordinary: */10 * * * * sudo /usr/local/bin/waha-session-watch /opt/waha-watch/cron.log 2 &1. However, upon investigation, it was discovered that the cron log never filled up, and the watchdog's own log, watch.log, had no entries from cron runs. The tool was running manually, but not through cron as scheduled.\n\nThe root cause of the issue was the redirection of the command output to a log file. The crontab line redirected the output to /opt/waha-watch/cron.log, but the file didn't exist and waha, the user running the command, didn't have write permissions in the directory. This caused the process to fail and not run at all, even though it appeared to be running based on the crontab line.\n\nThe fix was simple: create the log file in advance, owned by the user running the command. Once the log file was created, the watchdog ran successfully without any code changes. The lesson learned was that crontab -l only confirms the storage of the job, not its execution. To verify a scheduled job, one should check both the scheduler's record and the tool's own log for entries matching the schedule. Additionally, if a command redirects output to a log file, ensure the file is created ahead of time, owned by the user running the command.",
  "summary": "I write monitoring so I don't have to watch things by hand. So there is a special kind of dread in discovering that the monitor you installed to watch production has itself been dead since the day you installed it — and that everything you would normally check said it was fine. This one was dead for five days. Here's the autopsy, because the failure mode is boring, extremely common, and almost…",
  "key_points": [
    "Monitoring tool failed to run for five days",
    "Crontab line redirected output to non-existent log file",
    "Fix involved creating log file owned by running user"
  ],
  "editors_take": "A misconfigured log file redirect in the crontab line prevented a scheduled monitoring tool from running, highlighting the limitations of relying solely on crontab -l to verify job execution.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}