Download the PHP package aleblanc/simple-cron-scheduler without Composer

simple-cron-scheduler

Symfony bundle to orchestrate cron through a single crontab entry + a declarative schedule (PHP attributes or YAML), with subprocess isolation by default. No Messenger, no long-running daemon. MIT.

Targets Symfony 7.2 → 10, PHP 8.4+.

Everything else lives in your application code.

Why this bundle

It is an alternative to symfony/scheduler that needs neither Messenger nor Supervisor. symfony/scheduler dispatches its tasks through Messenger: you need a transport and a messenger:consume worker kept alive by a process supervisor (Supervisor, systemd…) that you deploy and monitor. simple-cron-scheduler removes all of that: the cadence comes from the OS cron (* * * * *), which wakes a fresh process every minute. No worker to keep alive, no transport, nothing to supervise — a crash has nothing to restart.

In spirit it is close to Laravel's scheduler (a single crontab line, a declarative schedule in code, @daily macros, between windows, environment restriction) — brought to Symfony with a repeatable #[AsCronTask] attribute, native shell tasks, and per-task memory isolation via subprocess on top.

Installation (automatic, with Flex)

The package ships a Flex recipe: the quickest way is to point your app at this repo as a custom recipe endpoint, then require the package — the bundle and config are wired automatically.

1. Add the recipe endpoint to your app's composer.json:

2. Require the package — the recipe runs on install:

This registers the bundle in config/bundles.php, creates config/packages/simple_cron_scheduler.yaml, and prints a post-install reminder. The bundle's configuration alias is simple_cron_scheduler.

3. Add the single crontab entry on the server (the only manual step — Flex does not touch the crontab):

That's it — no worker, no Supervisor. Check your tasks with php bin/console scheduler:run --list.

Without the recipe (or before tagging a release), do it by hand: add SimpleCronScheduler\SimpleCronSchedulerBundle::class => ['all' => true] to config/bundles.php, create config/packages/simple_cron_scheduler.yaml (a minimal simple_cron_scheduler: { timezone: Europe/Paris } is enough), then add the crontab line. Recipe details: recipes/README.md.

Declaring tasks with an attribute (#[AsCronTask])

The attribute is repeatable: stack several schedules on the same command, with different arguments.

#[AsCronTask] fields

Declaring tasks in YAML (shell / command / service)

config/packages/simple_cron_scheduler.yaml:

Each entry has exactly one of command:, shell: or service: — otherwise it fails at boot. All runtime fields (skipMinutes, skipHours, skipDays, skipMonths, days, between, unlessBetween, env, when, description, group, disabled, lock, runner, timeout) are available in YAML too:

A full example lives in doc/examples/simple_cron_scheduler.yaml.

Calendar conditions

Beyond the cron expression itself, these additive filters refine when a task runs (all of them must pass; any match on a skip* list excludes the run):

They combine freely — e.g. days: [1..5] + skipHours: [0..5] = weekday business-hours only. When a task is ruled out, a TaskSkippedEvent is dispatched with the matching reason (skipHours, days, skipDays, skipMonths, …).

Execution modes (runners)

• process (default): each command runs in a php bin/console subprocess. An OOM, a segfault or an exit(255) does not affect the other tasks. memory_limit is reset for each task.
• in_process: runs in the current process (zero overhead, but no memory isolation). Good for short, predictable tasks and tests.
• shell: Process::fromShellCommandline() → pipes, &&, redirections. No PHP involved.
• service: invokes a service __invoke(\DateTimeImmutable $now) in the current process.

Global via default_runner, overridable per task via runner:.

PHP binary resolution. The process runner spawns php bin/console …. By default (no php_binary config) the binary is resolved at runtime via PhpExecutableFinder, which uses the PHP currently running scheduler:run — so it works the same on macOS (Symfony CLI), in Docker, and on the server, even when var/cache/ is shared between host and container. Pin it explicitly only if you need to: php_binary: '/usr/bin/php'.

when conditions

Create a service implementing CronCondition (auto-tagged — no config needed):

Reference it by its service id (= FQCN with default autowiring):

Observability — events

Each run dispatches Symfony events. Wire your own listeners (alerts, email, metrics):

Example — email the output on failure (Laravel's emailOutputOnFailure equivalent):

Logging

Each finished/failed task is logged on a dedicated Monolog channel (log_channel, default scheduler) — the bundle declares the channel to MonologBundle automatically, so you can route it to its own file without touching the bundle:

Rename the channel via config if you prefer:

If MonologBundle is not installed, logging is silently skipped (the command falls back to a null logger) — the bundle stays fully usable.

Anti-overlap

Overlap is handled per task, not globally — so a single slow task can never block the others.

• Per-task lock (lock: true, the default): before running a task, the scheduler acquires an OS-level lock (symfony/lock + FlockStore) named after the task. If a previous tick is still running that same task (e.g. it takes longer than a minute), the new run skips only that task (a TaskSkippedEvent with reason locked is dispatched; -v prints task -> skipped (locked, still running)). All other due tasks run normally. The flock has no TTL: it is held for the whole task and released on completion (or process death), so even multi-minute tasks are protected. Set lock: false on a task you explicitly want to allow running concurrently with itself.

• scheduler:run is NOT globally locked by default (lock_runner: false), so you can run several ticks concurrently — a long task in the previous tick does not prevent the next tick from starting the other tasks. Set lock_runner: true if you really want the old "one whole tick at a time" behavior.

Optional belt-and-suspenders at the crontab level for slow Symfony boots (only if you set lock_runner: true):

Commands

Add -v to stream subprocess output live, line by line, prefixed with the task name ([task-name] …) — useful for long-running tasks where Process would otherwise buffer everything and only return at the end (looking like a hang). -v also prints task -> starting / task -> exit N (Xms) markers.

Tests & quality

Configs: phpstan.dist.neon (level 8, src + tests) and .php-cs-fixer.dist.php.

License

MIT