Receive cron-job notifications

Prepare the notification script

1. Create a bot in the web console and save its Client ID and Client secret.
2. Open the bot’s chat in BotComm on iOS or the web. Without a target Session ID, messages go to the owner’s chat.
3. Enable notifications in the app and your device settings if you want a push alert.

This example assumes a Unix-like machine with cron, a POSIX shell, and Python 3.6 or later. Save the script from the Python guide as /opt/botcomm/notify.py, or choose a directory owned by the account that runs your job.

Create /opt/botcomm/credentials.env with the following contents. Keep this file readable only by the job’s account, for example with chmod 600 /opt/botcomm/credentials.env.

export CLIENT_ID='YOUR_CLIENT_ID'
export CLIENT_SECRET='YOUR_CLIENT_SECRET'

Cron does not load your interactive shell profile. Loading this file explicitly makes the credentials available to Python when cron starts the job.

Wrap your existing job

Save this as /opt/botcomm/run-report.sh. Replace /opt/jobs/daily-report.sh with your real command and adjust the Python path if needed. Make sure the job’s account can read these files and run your command.

#!/bin/sh
set -u

# Load a file readable only by the account running this job.
. /opt/botcomm/credentials.env

/opt/jobs/daily-report.sh
job_status=$?

if [ "$job_status" -eq 0 ]; then
  message="Daily report completed successfully."
else
  message="Daily report failed with exit code $job_status."
fi

if ! /usr/bin/python3 /opt/botcomm/notify.py "$message"; then
  printf '%s\n' 'BotComm notification failed; check the job log.' >&2
fi

exit "$job_status"

Run /bin/sh /opt/botcomm/run-report.sh manually as the cron account first. Your report script must exit nonzero when it fails. The wrapper records that status before sending the notification, so a notification problem does not hide the job’s result.

Schedule the wrapper

Open the job account’s crontab with crontab -e and add:

0 9 * * * /bin/sh /opt/botcomm/run-report.sh >> /opt/botcomm/report.log 2>&1

This runs daily at 09:00 in the cron daemon’s configured time zone. Ensure the account can write the log file, and arrange log rotation if you keep this running. Use absolute paths inside the report script too, or explicitly change to its working directory.

For alerts only on failure, move the notification call into the wrapper’s failure branch. Avoid repeatedly alerting on a persistent failure without a pause or deduplication.

Troubleshooting

• Works manually, but not in cron: check the cron account, file permissions, absolute paths, and credentials file. Read report.log for Python and HTTP errors.
• No run and no log: check that the cron service is running and the schedule is installed for the correct account.
• HTTP 401 or 404: verify the credentials and open the bot’s chat. See Python troubleshooting.
• No completion message: the job may still be running, have been killed, or the host may be offline. This wrapper sends only after the command returns; it cannot detect a host that never starts the job. Use external monitoring if you need missing-run alerts.
• Duplicate messages: check for overlapping schedules or retries after a timeout. Automatic retries are deliberately omitted because a timed-out send may already have succeeded.

Check your system’s man 5 crontab for scheduling behavior; the Linux crontab manual describes a common implementation.