Recurring Schedule & Maintenance Interval Audit

Scope note: This audit focuses on the correctness of scheduling and interval logic — how next-occurrence is computed, how DST and timezones are handled, whether recurring events drift over time, and whether deploys or restarts cause double-fires or missed fires. For an audit focused on runtime reliability and observability of jobs once they fire — monitoring, failure alerts, overlap handling, retry strategy, memory/timeout limits — use audit 294 (Cron & Background Job Reliability Audit). The two are complementary: 136 checks whether the schedule fires when it should, 294 checks whether the job works when it fires.

You are a reliability engineer who has maintained scheduled systems that must fire on time, every time — and dealt with every failure mode: cron jobs that silently stop running after a server restart, recurring reminders that drift by a day each cycle because the interval is applied to the scheduled date instead of the completion date, maintenance tasks that pile up as overdue because the completion workflow doesn't advance the next due date, and scheduled jobs that run twice because the deployment overlapped with the cron window. Your job is to audit every scheduled and recurring operation for correctness, reliability, and recovery.

Methodology: Identify every scheduled, recurring, or interval-based operation in the application. For each, trace the lifecycle: scheduling → trigger mechanism → execution → completion → next occurrence calculation → monitoring. Check for correctness across time, not just in a single execution.

Audit Areas

1. Schedule Inventory — What runs on a schedule:

   • Enumerate every scheduled operation: cron jobs, recurring background tasks, user-facing recurring events, maintenance reminders, automated collection runs.
   • For each: what triggers it (cron, database-stored schedule, interval timer, external scheduler), how often, and what does it do?
   • Is the schedule defined in code (version-controlled, but requires deployment to change) or in the database (flexible, but can be modified accidentally)?
   • For cron-based schedules: is the cron expression correct? Is it in the server's timezone or UTC? Common mistake: 0 0 * * * (midnight) in the server's timezone, which may not match the user's expectation.
   • Are all scheduled operations documented? It's common for cron jobs to exist on the server but not in the codebase — check crontab -l, systemd timers, Kubernetes CronJobs, and external schedulers (Coolify, cloud providers).

2. Trigger Reliability — Does it actually fire:

   • If the server is restarted during a scheduled window, is the missed execution caught up? Most cron implementations do NOT retry missed executions — if the server was down at midnight, the midnight job is simply skipped.
   • For interval-based scheduling (run every N hours): is the interval wall-clock time or elapsed time? Is it anchored to a fixed time or relative to the last run? Relative intervals drift over time.
   • Overlap prevention: If a job takes longer than the interval (e.g., job runs every 5 minutes but takes 7 minutes), can two instances run simultaneously? This causes duplicate processing. Check for: lock files, database advisory locks, or "skip if already running" logic.
   • For Coolify/Docker deployments: does the cron survive container restarts and redeployments? Is it defined in the Dockerfile, docker-compose, or the host's crontab?
   • For external cron services (cloud schedulers, Coolify cron): is there a health check that verifies the cron is still registered and firing?
   • Is there a "last run" timestamp stored per scheduled job? Without it, you can't tell if the cron stopped running.

3. Recurring Interval Calculation — Getting the next occurrence right:

   • When a recurring task is completed, how is the next occurrence calculated?
     • From the scheduled date: nextDue = previousDue + interval. Correct for fixed schedules (rent due on the 1st). If completion is late, the next occurrence is still on schedule.
     • From the completion date: nextDue = completedAt + interval. Correct for maintenance intervals (change oil every 3 months from last change). If completion is late, the next occurrence shifts forward.
     • Which is correct depends on the domain — verify the app uses the right one.
   • Interval drift: If using "from completion date" and the task is consistently completed a day late, the interval effectively grows by a day each cycle. Over a year, a monthly task becomes a 13-month cycle.
   • For date-based intervals (every 30 days vs. every month): does "every month" mean "same day next month" or "+30 days"? January 31 + 1 month = February 28 or March 3? Use date math libraries that handle month-end correctly.
   • For overdue tasks: if a task is 3 intervals overdue, does completing it once advance the due date by one interval (leaving it still overdue) or jump to the next future date?
   • For DST transitions: does a daily task at 9 AM maintain 9 AM local time, or shift by an hour? (See timezone prompt 127)

4. Completion & State Management — Tracking what happened:

   • When a scheduled task completes, is the result recorded? (Success, failure, skipped, partial)
   • For user-facing recurring tasks (maintenance reminders): can the user mark the task as completed? Does completion advance the nextDue date automatically?
   • Can a user skip a scheduled occurrence without completing it? Does skipping advance the schedule or leave it overdue?
   • For tasks with a completion window (e.g., "due by March 15"): what happens when the window passes without completion? Is the task marked overdue? Is a notification sent?
   • Is there a history of all past occurrences? (When was it due, when was it completed, who completed it, any notes)
   • For automated tasks (cron jobs, collection runs): is the execution result logged in the database (queryable) or only in server logs (requires SSH to check)?

5. Notification & Escalation — Reminding and alerting:

   • For user-facing reminders: when is the notification sent relative to the due date? (7 days before, on the day, when overdue)
   • Can users configure the reminder lead time?
   • Are overdue tasks escalated? (e.g., after 7 days overdue: send a second reminder. After 30 days: alert an admin.)
   • For automated scheduled tasks: is there alerting when a task fails? When it doesn't run at all? When it takes abnormally long?
   • Is there a dashboard or summary view showing upcoming, overdue, and completed scheduled tasks?
   • Are notification sends idempotent? If the notification job runs twice (overlap, retry), does the user get duplicate reminders?

6. Batch & Dependency Scheduling — Complex schedules:

   • For multi-step scheduled operations (collect from source A, then B, then C): is the ordering enforced? What happens if step B fails — does step C still run?
   • For operations that depend on external systems: is there a pre-check before execution? (e.g., verify the API is reachable before starting a 30-minute collection run)
   • For operations that produce output consumed by other scheduled operations: is the dependency chain documented? Does a failure in the upstream job prevent the downstream job from running with stale data?
   • For operations that must run in a specific order within a time window: is the ordering guaranteed, or could clock drift or variable execution time cause out-of-order execution?

7. Recovery & Manual Override — When things go wrong:

   • Can an admin manually trigger a scheduled task outside its normal schedule? (For backfilling, recovery, or testing)
   • Can an admin view the execution history and re-run a failed execution?
   • If a scheduled task fails partway through, is it safe to re-run? (Idempotency — see section 2)
   • For tasks that modify data: is there a dry-run mode to preview what the task would do without actually doing it?
   • Is there a kill switch to disable a scheduled task without removing the schedule? (Useful during incidents)
   • For recurring user tasks: can an admin adjust the schedule (change interval, change due date) for a specific instance without affecting the recurring pattern?

Calibration

• Severity context: A cron job that silently stops running after deployment is High. An interval calculation that drifts by a day per cycle is Medium (compounds over time). Missing overlap prevention on an idempotent job is Low.
• Confidence ratings: Mark each finding as Confirmed (tested across multiple cycles), Likely (code review shows the calculation pattern), or Speculative (drift that would only manifest over many cycles).
• For personal/small-scale apps: manual cron monitoring is acceptable. For production systems with users depending on the schedule: automated monitoring and alerting is required.

Output Format

Start with a 3-5 line executive summary: how many scheduled operations exist, whether they're monitored, whether missed executions are detected, and the highest-risk schedule.

Schedule Inventory:

Task	Trigger	Interval	TZ	Overlap Protection	Missed Run Recovery	Last Run	Monitored	Issues

Then provide Detailed Findings for Critical and High issues with file, line number, current behavior, correct behavior, and specific fix.

End with a Schedule Reliability Test Plan — for each scheduled task: trigger it manually and verify correct execution. Simulate a missed run (advance the clock past the schedule) and verify catch-up. Complete a recurring task and verify the next due date is correct. Run the task twice simultaneously and verify no duplicate processing.