How to Automate a Weekly Competitor Digest With a CLI and Cron
A Short Script, One Crontab Line, and the Failure Modes Nobody Mentions
Short answer
Automate a weekly competitor digest with a short script and one cron line. The script runs the same read-only CLI commands every week and saves the output to a dated file or message. Use a durable API key, full paths and a failure alert, because scheduled jobs usually fail silently rather than loudly.
1. What should a weekly competitor digest contain?
Four blocks: what changed, which change matters and why, a comparison against last period, and the one decision or action it suggests. Everything else is reference material that belongs in the tracking tool, not the digest.
| Block | Question it answers | Length |
|---|---|---|
| What changed | Which competitors did something new this week? | Three to seven bullets |
| What matters | Which of those changes affects our positioning, pricing or plans? | One or two short paragraphs |
| Compared with before | Is this a trend or a one-off? | One comparison per key competitor |
| Suggested action | What should someone do this week because of it? | One line, with an owner |
Automation makes the collecting free, which tempts people to include everything. Resist it. The digest is valuable because it is short enough to read on Monday morning. Link to the full data instead of pasting it.
2. Do I need cron at all?
Not if your tracking tool can already schedule the report you want. Use a script and cron when you need to combine outputs, send them somewhere the tool does not support, or keep dated files you can diff.
Check the simple route first. The Oppira CLI can create a scheduled email report from a plain-language brief, for example oppira reports create --prompt "weekly rival ad moves" --frequency WEEKLY --day 1 --hour 8. Once created, it runs inside Oppira and needs no machine of yours to stay awake. Run oppira reports --help to see how days and hours are specified and how to list, update or run reports.
A script earns its place when you want more than one report can do: several commands stitched into one file, output delivered to a chat channel or shared drive, a dated archive you can compare week against week, or a step that passes the week into another tool. That is what the rest of this guide builds.
3. How do I build the digest script?
Write a script that fails fast, runs a fixed set of read-only commands, writes everything to one dated file, and exits non-zero if any step fails. Test it by hand before scheduling it.
Save this as a file such as competitor-digest.sh in a folder of your own, and make it executable with chmod +x. Veltrix and Sondera stand in for your tracked competitors.
- Start with a strict header. First line #!/usr/bin/env bash, second line set -euo pipefail. The second line makes the script stop at the first failed command instead of mailing a half-empty digest.
- Name a dated output file. Add OUT="$HOME/digests/competitors-$(date +%F).md" so each week lands in its own file, such as competitors-2026-09-28.md. Dated files are what make week-on-week comparison possible.
- Collect the week. Inside a block that redirects to "$OUT", run oppira insights summary for the weekly summary, then oppira comp compare Veltrix Sondera --months 6 for the head-to-head trend.
- Ask for the so-what. Add oppira ask "What changed with my competitors this week that should change our plans? Five bullets, name the competitor." --json | jq -r .text so the file ends with a short narrative rather than raw data.Keep the question identical every week. A fixed prompt makes the answers comparable, and a changed prompt makes a quiet week look like news.
- Run it by hand, twice. Run the script from your terminal and read the file. Then run it again from a different folder. If the second run fails, the script depends on your working directory, and cron will hit the same problem.
Every command in this script only reads. That is deliberate: an unattended job should never be able to publish, change a campaign or spend money. Keep commands such as studio quick-post or ads changes out of scheduled scripts entirely.
4. How do I schedule it with cron?
Add one line to your crontab with crontab -e: minute, hour, day of month, month, day of week, then the full path to the script and a log file. Monday at 07:17 is 17 7 * * 1.
| Field | Value | Meaning |
|---|---|---|
| Minute | 17 | At minute 17 |
| Hour | 7 | Of hour 7, in the time zone of the machine |
| Day of month | * | Any day of the month |
| Month | * | Any month |
| Day of week | 1 | Monday (0 is Sunday) |
| Command | Script path, then >> log 2>&1 | Run the script and append both output and errors to a log |
The four reasons a script that works by hand fails under cron:
- PATH is minimal. Cron does not load your shell profile, so node, oppira and jq may not be found. Use full paths in the script, or set PATH at the top of the crontab where your cron supports it.
- The working directory is different. Use absolute paths for every file the script reads or writes.
- Authentication. The job runs as your user but without an interactive login, so create a durable key with oppira auth key generate and check oppira auth --help for how to use it on that machine.
- The machine is asleep. Cron on a laptop does not run while the lid is closed. For a job that must run, use an always-on machine or a CI scheduler.
5. Can I run the digest in CI instead of on my own machine?
Yes. A scheduled CI workflow runs the same script on hosted infrastructure, so it does not depend on your laptop. Store the key as an encrypted secret and expect schedule times in UTC, with occasional delays.
GitHub Actions, for example, accepts the same five-field cron syntax in a schedule trigger. As of September 2026, GitHub documents that scheduled workflows run in UTC by default, the shortest interval is once every five minutes, schedules can be delayed during high load (with the start of every hour called out as a high-load time), and scheduled workflows only run from the default branch [s2].
Two consequences for a digest. Pick an off-the-hour minute, such as 17 rather than 0, to dodge the busiest moment. And convert your local Monday morning to UTC when writing the schedule, or the digest arrives on Sunday night for half the team.
6. How do I keep an automated digest worth reading?
Alert on failure, cap the length, keep the questions fixed, and review the prompt once a quarter. An automated digest decays in two ways: it silently stops, or it silently becomes noise.
Make failure loud. Because the script exits non-zero when a step fails, you can have the scheduler notify you, or add a final line that posts a short failure message to your team channel. A digest that quietly stops arriving is usually noticed weeks later.
Make noise visible. Keep an eye on the length of each dated file. If it keeps growing while nothing changes in the business, the prompt is too open. Tighten it to a fixed number of bullets and a named decision.
Keep a person at the end. The digest informs a decision; it does not make one. If a week shows Veltrix cutting its entry price, the script can surface it on Monday, and a person decides by Tuesday whether it changes the plan.
Key Takeaways
Four blocks, short
What changed, what matters, compared with before, and one suggested action. Link to the rest.
Try the built-in schedule first
If your tool can send the report on a schedule, you may not need a script. Use cron when you need to combine or route output.
Read-only commands only
Unattended jobs should never publish or spend. Keep write commands out of scheduled scripts.
Cron is not your shell
Minimal PATH, a different working directory and no interactive login cause most silent failures. Use full paths and a durable key.
CI schedules run in UTC and can slip
Convert the time zone, avoid the top of the hour, and keep the repository private.
Fixed prompts make weeks comparable
Ask the same question every week so a change in the answer means a change in the market.
Frequently Asked Questions
Sources
- crontab: schedule periodic background work (POSIX) The Open Group, January 2018.The standard definition of the five crontab time fields.
- Events that trigger workflows: schedule GitHub, September 2026.UTC scheduling, minimum interval, high-load delays, default-branch rule and the 60-day inactivity pause.
Explore More
Related analyses, benchmarks, and industry insights
Related Guides
Glossary Terms
Turn reading into a reaction
Oppira watches your competitors, keeps your playbook current, and drafts the response. See your market clearly by tomorrow.