fgits/cron-bundle
fgits/cron-bundle is a Symfony bundle for managing cron jobs from configuration, letting you define, schedule, and run recurring tasks without editing system crontabs directly. It integrates cron expressions with your app's services and provides commands to list and execute due jobs.
Reality check first: this is a Symfony bundle, not a Laravel package. Its description — "scheduled execution of Symfony commands" — means it wires into the Symfony console/kernel and a config/bundles.php entry. If you are working in a Laravel codebase, there is no clean integration path; Laravel's Schedule::command() already covers this ground with first-party support, overlap locks, and onOneServer() semantics. The guidance below assumes you have inherited or joined a Symfony project that already depends on this bundle (or has a hard requirement to).
Ecosystem mismatch aside, the onboarding path for a Symfony app:
Pull it from the private forge, not Packagist. With zero dependents there is almost certainly no tagged release of note, so register the repository explicitly and pin a commit:
{
"repositories": [
{ "type": "vcs", "url": "https://git.fgit.de/libs/fgits-cron-bundle.git" }
],
"require": {
"fgits/cron-bundle": "dev-main#<commit-sha>"
}
}
Register the bundle. Modern Symfony Flex: add the class to config/bundles.php (Fgits\CronBundle\...::class => ['all' => true]). The exact namespace is derived from the bundle name — confirm it from composer.json's autoload.psr-4 rather than guessing.
Read three files before anything else, in this order:
DependencyInjection/Configuration.php — the authoritative list of every option the bundle accepts. This is the documentation.Command/ — the console entry points it exposes (you are looking for something like cron:run / cron:list).Resources/config/services.yaml — how it registers jobs, whether it dispatches events, and what it tags.First use case: schedule one low-risk existing command (a cache warmer or a report generator) purely through bundle config, then add a single system crontab line that ticks the bundle's runner every minute:
* * * * * cd /var/www/app && php bin/console <bundle-run-command> >> var/log/cron.log 2>&1
Confirm the runner name with php bin/console list | grep -i cron before committing the crontab entry.
One real cron line, many logical jobs. The entire value of a bundle like this is that the system crontab has exactly one entry; the bundle owns the "what is due right now" decision. Resist the temptation to also add raw crontab lines for the same commands — you will end up with two sources of truth and jobs that fire twice.
Declarative config for stable jobs, console commands for complex ones. Define the schedule (expression, command name, args) in YAML/PHP config so it is reviewable in a diff. When a job grows argument-parsing, locking, or multi-step logic, promote it to a dedicated console command and have the bundle invoke that — don't let config become a scripting language.
Per-environment schedules. Use Symfony's when@prod / when@dev blocks so staging gets a slower cadence (or a subset of jobs) without a second config file:
# config/packages/prod/fgits_cron.yaml
fgits_cron:
jobs:
report_daily:
command: 'app:report:daily'
expression: '0 2 * * *'
Verify the top-level key against Configuration.php — bundle config keys rarely match the package name exactly.
Overlap protection is your responsibility unless proven otherwise. A bundle with no community will typically not ship distributed locking. For any job that can exceed its interval, wrap the work in Symfony's Lock component (LockableTrait in the command, or a flock around the runner) so a slow run cannot stack.
Observability. Route the runner's output into Monolog via a handler, and make each job emit a start/finish line with duration. Exit codes matter more than logs: make sure a failing child command propagates a non-zero status so your monitoring (Sentry, Healthchecks.io, a dead-man's-switch ping) actually fires.
Testing. Use Symfony\Bundle\FrameworkBundle\Console\Application + CommandTester in a KernelTestCase to assert the runner selects the right jobs. If the bundle exposes schedule computation as a service, unit-test that in isolation with an injected clock rather than sleeping in tests.
git.fgit.de, and budget time to read Configuration.php end to end. Availability of that host is now a build dependency.composer update can silently move you onto a new dev-main. Lock it down in composer.json and keep composer.lock in version control.php bin/console cache:clear. Symptom: a changed cron expression appears to be ignored. Use php bin/console debug:config <bundle_alias> to see the resolved tree rather than re-reading YAML.date.timezone (or framework.default_locale-adjacent settings) and the system cron daemon's timezone can differ by hours. Decide which one owns the expression semantics and write it down; DST transitions are the classic cause of "the 02:00 job didn't run."bin/console list to confirm the command exists, (2) run the target command manually, (3) run the bundle runner with -vvv and a narrowed schedule, (4) check debug:container --tag= for the expected tag, (5) only then suspect the expression.cron.before_run / cron.after_run), a job-type registry, or a compiler pass. If none exist, the cleanest extension is a thin decorator around the runner service in your app's services.yaml rather than forking the bundle.cron/cron-bundle or Symfony's own Symfony\Component\Scheduler — both have far more eyes on them. Adopt this one only if it is already load-bearing in the codebase you inherited, and then keep the integration thin enough to swap out.How can I help you explore Laravel packages today?