What this prompt does
This prompt builds a cron job management wrapper for a [environment_type] running [job_count] scheduled tasks. It creates a cron-runner.sh that logs stdout, stderr, exit code, and duration to [log_directory], flock-based locking to prevent overlapping runs with a [lock_timeout]-minute stale-lock guard, alerts via [alert_channel] on failure or overrun by [timeout_multiplier]x, a SQLite execution history, a status table over the past [history_days] days, log rotation keeping [retention_days] days gzipped, and a YAML-to-crontab generator.
The variables encode the guardrails. [lock_timeout] and [timeout_multiplier] define when a job is considered stuck or stale, [alert_channel] routes failure notifications, and [history_days] plus [retention_days] control how much history the status view and logs keep. The YAML config turns ad-hoc crontab lines into a reviewable file where each job declares its schedule, command, timeout, and recipients.
When to use it
- You have been burned by silent cron failures or overlapping runs
- You want per-run logging capturing exit code and duration for every job
- Preventing overlapping executions with flock and a stale-lock timeout
- Alerting when a job fails, runs late, or exceeds its expected runtime
- You want a status command showing last run, last status, and failure rate
- Turning ad-hoc crontab lines into a reviewable YAML config
Example output
Expect a cron-runner.sh wrapper, a flock locking mechanism, an alerting function targeting [alert_channel], a SQLite schema and insert logic for execution history, a status command rendering a table over [history_days] days, a logrotate-style config keeping [retention_days] days, and a generator that reads YAML and emits a crontab. Each piece is a focused script tied together by the runner.
Pro tips
- Set
[lock_timeout]longer than a job's worst-case runtime, or a legitimately long run gets killed as a stale lock - Tune
[timeout_multiplier]against real durations; too low and you get false overrun alerts, too high and a hung job goes unnoticed - Route critical alerts through a channel you actually watch via
[alert_channel]— a Slack message no one reads is not monitoring - Keep
[retention_days]aligned with disk capacity in[log_directory]; verbose jobs can fill a partition faster than expected - Use the YAML-to-crontab generator as the single source of truth so cron changes go through review instead of manual edits
- Have the status command surface failure rate over
[history_days]so a job that fails intermittently is visible, not just hard-down jobs - Capture both stdout and stderr per run; the error you need during an incident is almost always on stderr, and a wrapper that only logs stdout hides it
- Keep the SQLite history pruned in step with
[retention_days]and rotate logs in[log_directory]so the management layer itself does not become the thing that quietly fills the disk it is meant to protect
