Cron Job Conflict Detector

What this skill does

Reads a set of cron specifications (with each job's expected runtime) and detects pairs of jobs likely to overlap, risking contention or double-running. Outputs a conflict matrix and proposes staggered schedules.

Inputs

• jobs_file: a YAML or CSV with rows {name, schedule, expected_duration_minutes, host_or_pool}.
• Optional lookahead_days: how far ahead to project (default 14).
• Optional concurrency_limit_per_pool: defaults to 1.

Steps

1. Validate each schedule with cron-parser's parseExpression. Reject invalid entries with file:line.
2. For each job, materialize the next N firings within lookahead_days.
3. For each firing, compute the [start, start + expected_duration] interval.
4. Bucket intervals by host_or_pool so contention is per pool.
5. For each pool, sweep the timeline: detect when more than concurrency_limit_per_pool intervals overlap. Each such window is a conflict.
6. For each conflict window, list the involved jobs, the overlap duration, and the maximum concurrent count.
7. Compute "noisy neighbors": jobs that participate in the most conflicts.
8. Suggest fixes: shift the lower-priority job (heuristic: shorter cadence shifts to a different minute; longer cadence stays); use flock or distributed locking; change the cron expression to add jitter (e.g., */5 * * * * -> 2,7,12,...).
9. Emit a markdown report.

Output

cron-conflicts.md with a summary header (total conflicts in window), per-pool conflict tables (timestamp, jobs, overlap minutes), and a per-noisy-neighbor suggestions list. Stdout prints noisiest job names.

Verification

Re-run with lookahead_days * 2 and confirm conflict counts scale roughly linearly — sub-linear scaling implies the schedules are sparser than expected, super-linear implies a clustering effect (e.g., everything fires at minute 0). Manually check a sample conflict by computing the next firings of the involved jobs in a separate script (e.g., python -c "from croniter import croniter; ..."). For suggested staggered schedules, re-run the detector and confirm conflicts drop.

Edge cases

• Jobs with @reboot schedule: cannot project; tag separately.
• Jobs spanning DST transitions: cron-parser handles them but durations may shift; warn near transition dates.
• Jobs with unbounded duration (e.g., backups whose duration depends on data size): use a percentile (p95) duration if provided; otherwise mark as unknown-duration and skip overlap checks.
• Jobs across multiple pools sharing a database: surface as cross-pool-shared-resource and let the user supply a downstream-resource graph.