backend-scheduling-cron

Backend Scheduling and Cron

Purpose

Implement distributed cron jobs and scheduled tasks with timezone awareness, leader election, and failure recovery so periodic work runs exactly-once across the cluster. Without distributed coordination, cron jobs on multiple instances cause duplicate execution, data corruption, and resource waste.

Agent Protocol

Trigger

Exact user phrases: "cron", "schedule", "scheduled task", "cron job", "job scheduling", "distributed cron", "cron expression", "timezone", "scheduler", "background job", "periodic task", "cron trigger".

Input Context

• Job definitions and their schedule (cron expressions).
• Distributed environment (Kubernetes, multi-instance).
• Existing infrastructure (Redis, PostgreSQL, ZooKeeper).

Output Artifact

Cron job configuration or scheduler code. No file unless requested.

Response Format

Job: {name}
Schedule: {cron expression}
Timezone: {IANA timezone}
Provider: {built-in|distributed-scheduler|external}

Completion Criteria

• Cron expression validated.
• Exactly-once execution guaranteed in multi-instance deployment.
• Timezone handling correct — DST transitions mapped.
• Error handling and retry configured.
• Monitoring and alerting for missed executions.

Max Response Length

3 lines per job. 15 lines for full setup.

Architecture Decision Tree

Which Scheduling Approach?

How many instances run the scheduler?
  ├── Single instance → Use built-in cron (OS-level or in-process)
  │   └── Risk: Single point of failure, no failover
  └── Multiple instances → Distributed scheduling required
      ├── Is the job is critical and must always run?
      │   ├── Yes → Use leader election + distributed lock
      │   └── No → Use low-priority scheduler with best-effort
      └── Do you need complex workflows or dependencies?
          ├── Yes → Use dedicated scheduler (Temporal, Airflow, Quartz)
          └── No → Simple distributed cron is sufficient