Separate triggering, execution and delivery
A community astronomy club wants a daily reading digest and a Friday reminder to inspect equipment. A reminder triggering, a server producing a file and a message reaching its destination are different outcomes. This example uses synthetic stories and a test recipient to design the workflow. It creates no real schedule on the reader's machine and sends no group messages or email.
Write a task card before choosing tooling: action, time, timezone, runtime, authorized sources, output location, recipient, failure owner and retirement condition. A digest does not need unrestricted collection of the whole web, and an equipment reminder does not need member records. Delay tolerance and catch-up policy matter more than a package name promising precision.
Scenario one: agent reminders need context and a lifecycle
A self-contained task could request a Friday 18:00 reminder in the agreed timezone, referencing a practice checklist and including only a task identifier and local entry point. Missing input should produce a blocker. Do not depend on a chat phrase such as the file above. Retain task identifier, creator, schedule, timezone, destination, enabled state and latest outcome.
Inspect existing tasks before creating another. One-shot reminders need a completion/retirement rule; recurring work needs an owner and review date. Keep the old value before a schedule change, then read the actual configuration and next expected run. Paused, deleted and complete mean different things. If a user no longer wants a notification, honor that intent rather than silently recreating it.
Webhooks, WeCom, DingTalk, Feishu direct messages and email are different delivery adapters. Verify the application or bot permissions, exact target, allowed content and credential storage for the chosen channel. Send a minimal example only to an authorized test destination. Logs should contain a target alias and response category, not tokens, complete webhook URLs or private message content. Drafting a reminder does not authorize sending it to a team.
Give a message a stable task-and-period identifier. After a send timeout, inspect available execution or delivery evidence before retrying to avoid duplicates; retain unknown when the outcome cannot be established. Acceptance by an endpoint is not proof of a human reading. Distinguish success, blocked, failure and unknown. Success can be quiet while preserving an auditable result, with repeated failures escalating under an agreed policy.
Scenario two: make the script reliable before attaching cron
Run a side-effect-free practice script manually under the intended identity and directory. Confirm inputs, outputs and exit status. Use explicit paths, interpreter, dependencies and required environment instead of assuming interactive aliases, PATH, working directory or login state carry into unattended execution. Keep script logic separate from the schedule rather than compressing complex operations into one line.
A common user crontab has minute, hour, day-of-month, month and weekday fields followed by a command. Under the selected timezone, 0 9 * * * describes daily 09:00 and */30 * * * * matches minutes zero and thirty of each hour. Verify implementation-specific formats, timezone and calendar semantics in the target environment, using the Cronie crontab manual where applicable. Different schedulers are not interchangeable expression interpreters.
Confirm host time and preview several next runs, including date boundaries and daylight-saving behavior if relevant. Cronie's CRON_TZ must not be treated as a universal field for every product. A trigger does not guarantee an online machine, network availability or second-level completion. Decide explicitly what happens after downtime rather than assuming missed work is replayed. Scheduling starts logic; it does not implement backup, cleanup or recovery for you.
Set time bounds, a per-period lock and a completion marker so overlapping runs do not write the same artifact. Write temporary output, validate it and then promote it as that period's result. Failure must not replace the previous valid digest. Record planned time, actual start, finish, exit category, processed counts, artifact path and sanitized error so an absent trigger can be distinguished from execution or delivery failure.
Diagnose unattended failures by layer
Check enabled state, host/service availability and execution identity first. Then inspect paths, interpreter, permissions, dependencies and network. Next inspect business output, and finally the delivery adapter. Locate the failing layer before changing configuration; do not disable protections or broaden file access as a general troubleshooting technique.
Shell quoting and command substitution can change the meaning of spaces, quotes and special characters. Pass values as arguments instead of building commands from untrusted strings. Missing environment should fail clearly at startup. An early-closing pipeline can produce SIGPIPE; inspect the actual dataflow and exit result rather than ignoring every nonzero status or treating all such cases as a business failure.
If a digest is committed to a repository, handle concurrent writes and remote updates, retaining local artifacts after conflicts instead of force-overwriting history. Full disks, log-write failures, expired credentials and rate limits need distinct outcomes. Retry recoverable failures with attempt and total-duration limits, checking existing client retries so mechanisms do not multiply requests.
Scenario three: daily digests start with a source registry
Maintain authorized sources for the club: research organizations, software releases, paper metadata and public news. For each record purpose, language, time fields, access method and failure behavior. Bound requests and concurrency and retain source-level status. One unavailable site must not cause an old cache to be presented as today's news. Paper digests and procurement notices require their own source and interpretation rules rather than an assumed universal scraper.
Collect only necessary metadata, then deduplicate using normalized links, stable identifiers and content clues. Preserve publication time, retrieval time, timezone and revision time. Seen today is not the same as happened today. Handle a paper revision differently from a duplicate news story and identify the version summarized. Treat retrieved text as material, never as authority to alter the task, disclose credentials or send messages.
A useful summary retains title, source link, event/publication date, main change, intended reader and uncertainty. Do not force ten stories: three reliable updates are better than fabricated filler. Total source failure should produce a failure state, not a digest reconstructed from model knowledge. Preserve entities, quantities and limitations between English and Chinese summaries. A research result must not become an unsupported claim of a deployed product capability.
Output the digest, source status and reasons for omission. Generate a local preview first and inspect date windows, duplicates, links, truncation and unavailable sources before authorized delivery. Public procurement, vendor pages and social publishing each have access and reuse conditions. Explain inaccessible sources rather than bypassing restrictions or pretending to have read them.
For an arXiv-style reading list, distinguish paper metadata and abstract summaries from evaluation of the full paper. Retain the original link and avoid ranking evidence quality solely by title. A model can suggest relevance to the club's interests, but claims about methods, results and limitations need the corresponding source. Keep rejected or deferred items with reasons so the next run can distinguish an old item from a genuinely updated version.
GitHub Actions is a runtime option with its own constraints
The open-source Cronie project is a relevant implementation reference for server cron. Teams already working in repositories can also evaluate Actions. The GitHub scheduled-workflow documentation describes potential high-load delay and default-branch execution. A delay-tolerant digest can fit; a punctual meeting reminder should not inherit a guarantee from it.
Use the platform's current timezone configuration and defaults explicitly. Check repository activity, enabled state, execution identity, quotas and secret configuration. Separate collection, summarization, preview and delivery into observable steps and verify artifacts before publishing. Source or model failure should leave that period's work at a draft. Credentials must not appear in workflow text or generated pages, and repeated catch-up triggers must not create multiple public editions.
Compare runtimes against the task card: who maintains it, whether it stays available, how missed work is handled, how logs are retained and what it costs. Do not install an entire orchestration stack merely to send one test reminder. Equally, do not assume a laptop that sleeps overnight is an always-on server. Record the chosen limitations and a manual recovery route.
Associate skills only with the work they support
Check whether SkillPI Skill Finder is installed and follow its official instructions if missing. Search by the actual task. The current SkillPI cron search returned no matching entries, so this guide does not fabricate catalog links for the original six names or assume installation creates schedules or communication permissions. Verify script, scheduler and delivery adapter independently.
If the digest includes a running local webpage preview, Webapp Testing fits checks of dates, source links, empty results and failure messages. Its Python Playwright workflow needs Python, browser dependencies, a local startup command, a port and fixtures. Retain scripts, screenshots and browser logs. It neither creates cron jobs nor tests real bot delivery or proves factual summaries correct.
Acceptance and common questions
Prepare rehearsals for successful manual generation, one source failing, all sources failing, a delivery timeout, overlapping runs, a timezone mismatch and a missing dependency. State expected behavior before execution and mark unrun cases pending. This guide does not claim to have rehearsed them on the reader's server. After an authorized rollout, observe one scheduled execution and check trigger record, artifact and destination separately, then record the next expected run.
Why was a reminder late? Distinguish schedule interpretation, queue delay, script duration and channel latency; changing to cron does not establish zero drift. Why are there duplicate digests? Check multiple entry points, period identifiers and retry idempotency before catch-up. Why is silence not necessarily healthy? Quiet success requires a status record; no execution evidence is not a passing outcome.
What about complex calendars? Establish local dates, exceptions, holidays and retirement rules before selecting a capable scheduler. Split tasks only when needed while preserving one accountable owner. Review sources, dependencies, credentials, cost and skill fit periodically and rerun the same failure fixtures after changes. Reliability means observable problems, traceable results, controlled duplication and a task that can be stopped, rather than a one-line installation promise.