Yacron: Why Docker Containers Need a Different Kind of Cron

Hook

Traditional cron was designed in 1975 for multi-user Unix systems—and it shows. Try running cron in a Docker container and you'll immediately hit the daemon problem: containers expect foreground processes, but cron wants to hide in the background and log to syslog.

Context

The impedance mismatch between cron and containers runs deeper than process models. Container orchestrators like Kubernetes expect applications to log to stdout/stderr, crash loudly when they fail, and expose health checks via HTTP. Traditional cron does none of these things—it logs to syslog (which containers don't run), swallows errors silently, and provides no programmatic interface for monitoring.

Developers have worked around this with wrapper scripts, custom logging configurations, and kludges like running cron in the foreground with cron -f. But these workarounds miss the bigger opportunity: rethinking what a scheduler should look like in a cloud-native world. Yacron approaches the problem from first principles, asking what you'd build if you designed cron today for containers, microservices, and observable systems.

Technical Insight

Yacron's core insight is treating job scheduling as an async event loop problem rather than a daemon management problem. Built on Python's asyncio, it runs as a single foreground process that reads YAML configuration files and schedules tasks without forking into the background. This architectural choice cascades into several advantages for containerized environments.

Here's a minimal yacron configuration that demonstrates its YAML-first approach:

jobs:
  - name: database-backup
    command: /usr/local/bin/backup-postgres.sh
    schedule: "0 2 * * *"  # 2 AM daily
    captureStdout: true
    captureStderr: true
    onFailure:
      - shell: echo "Backup failed at $(date)" | mail -s "Alert" ops@example.com
    executionTimeout: 3600  # 1 hour max

Unlike traditional cron where failures disappear into the void, yacron makes error handling a first-class concern. The onFailure directive lets you define arbitrary actions—shell commands, HTTP webhooks, Sentry reports, or email notifications. This eliminates the need for wrapper scripts that check exit codes and manually implement alerting.

The real power emerges with yacron's retry and concurrency controls. Consider a job that hits an external API which occasionally times out:

jobs:
  - name: sync-customer-data
    command: python /app/sync_customers.py
    schedule: "*/15 * * * *"  # Every 15 minutes
    concurrencyPolicy: Forbid  # Don't start if previous run still active
    failsWhen:
      producesStdout: false  # Fail if nothing synced
    onFailure:
      retry:
        maximumRetries: 3
        initialDelay: 60
        maximumDelay: 600
        backoffMultiplier: 2
      report:
        sentry:
          dsn:
            fromFile: /run/secrets/sentry_dsn

This configuration implements exponential backoff (60s, 120s, 240s delays) and integrates Sentry error tracking without a single line of application code. The concurrencyPolicy: Forbid prevents job pile-up when tasks run long—a common problem with traditional cron where jobs can spawn indefinitely.

Yacron also solves the timezone problem that plagues cron. Traditional cron uses the system timezone, making daylight saving time transitions a nightmare. Yacron lets you specify timezones per-job:

jobs:
  - name: tokyo-office-report
    command: /app/generate-report.py --region tokyo
    schedule: "0 9 * * 1-5"  # 9 AM weekdays
    timezone: Asia/Tokyo

The optional HTTP REST API transforms yacron from a passive scheduler into a controllable service. Enable it with a simple config addition:

web:
  listen:
    - http://0.0.0.0:8080

Now you can query job status with GET /status or trigger jobs on-demand with POST /jobs/{job-name}/start. This enables integration with CI/CD pipelines, monitoring dashboards, and manual operations workflows—all impossible with traditional cron without building custom tooling.

Under the hood, yacron uses the parse-crontab library for schedule parsing and spawns jobs as subprocesses via asyncio's subprocess support. This means each job runs isolated with its own process tree, and yacron can capture stdout/stderr streams in real-time. The async architecture allows dozens of jobs to run concurrently without thread overhead, making it efficient even with frequent short-lived tasks.

Gotcha

Yacron's beta status isn't just a disclaimer—it reflects real gaps in production-readiness. The biggest missing piece is job state persistence. If the yacron process crashes or gets killed, all execution history disappears. There's no WAL (write-ahead log), no job completion database, no way to answer "did the backup run last night?" after a container restart. For critical scheduled tasks, this means you need external monitoring to verify job execution, which somewhat defeats the purpose of having integrated observability.

The Python 3.6+ requirement and asyncio foundation also create deployment constraints. While there's a standalone binary for Linux, it requires glibc 2.23+, which rules out Alpine Linux containers (they use musl libc). You'll need a Debian or Ubuntu base image, adding ~50MB to your container size compared to Alpine. Performance-wise, Python subprocess spawning is slower than native fork/exec, which matters if you're running hundreds of short-lived jobs. And finally, yacron has no distributed scheduling capabilities—each instance runs independently with no coordination, so you can't have hot standbys or guaranteed single-execution across a cluster without external locking mechanisms.

Verdict

Use if: You're running scheduled tasks in Docker or Kubernetes and need modern features like structured logging, failure notifications, and programmatic job control. Yacron excels when you want configuration-as-code with YAML, need per-job timezone handling, or require retry logic with exponential backoff. It's perfect for 12-factor apps where everything logs to stdout and services expose HTTP APIs. Skip if: You need battle-tested reliability for mission-critical infrastructure (stick with systemd timers or traditional cron), require job execution history that survives restarts, need Windows support, or are scheduling hundreds of sub-second jobs where Python subprocess overhead matters. Also skip if you're already deep in Kubernetes—native CronJobs provide better integration with k8s primitives like ConfigMaps and Secrets, though with less flexible configuration.