Chronos Laravel Package

Getting Started

Install the package with Composer, publish the Chronos config/provider assets as documented, clear config cache, and open the Chronos panel route. First place to look is config/chronos.php: confirm chronos.system_commands, test-command settings, and PHP binary overrides. A good first use case is scheduling one of your own Laravel commands from the panel, e.g. App\Console\Commands\SyncOrders, and running it once from the UI. App commands and Chronos commands are allowed by default; vendor/artisan commands are not.

Implementation Patterns

• Put business logic in app commands, then schedule and run those commands from Chronos. This keeps the default allowlist simple and avoids exposing framework/vendor commands.
• For needed system commands, allowlist by name or class:

  'system_commands' => [
      'cache:clear',
      'queue:restart',
      \Some\Vendor\Package\Commands\ImportCommand::class,
  ],
  

  Update any existing Chronos schedules that reference commands which are now blocked; those schedules are skipped until allowlisted.
• Use the panel for operational run/schedule flows and keep cron/schedule:run for infrastructure-level scheduling. Chronos is most useful for ad hoc runs, visibility, and command metrics.
• For staging/demo environments, set CHRONOS_TEST_COMMANDS=true if you need chronos:test, chronos:answer, chronos:dd, etc. Otherwise test commands only appear in local.
• When using “run in real time”, ensure the panel process and the command process agree on the PHP binary. Override with CHRONOS_PHP_BINARY if the panel runs under FPM/container PHP but the CLI php differs.
• If your commands handle SIGTERM themselves, Chronos preserves that handling; otherwise killed real-time runs are marked killed. Use this for graceful shutdown and queue-worker style commands.
• If Authorize middleware is enabled, publish the Chronos provider/config as required. Without it the panel can return 403 rather than a useful authorization error.
• Rely on Chronos command metrics for dashboards after upgrading: metrics accumulation and average calculation were fixed in 1.9.1. For real-time runs, expect only new log lines to be loaded.

Gotchas and Tips

• Upgrade-breaking behavior: system commands are disabled by default in 1.9.1. Existing schedules for commands like cache:clear or queue:restart will not run until listed in chronos.system_commands.
• Test commands are environment-gated: they are registered only in local; stage/prod panels will not show them unless CHRONOS_TEST_COMMANDS=true.
• PHP binary mismatch: real-time runs now use the running PHP binary instead of php from PATH. In containers, CI, or mixed FPM/CLI setups, set CHRONOS_PHP_BINARY explicitly.
• Signals and killed runs: SIGTERM/SIGKILL now reach real-time commands and killed runs get the killed state. If you rely on custom signal handling, verify it still behaves as expected.
• Laravel 13: 1.9.1 fixes real-time runs on new Laravel 13 apps with cache.serializable_classes = false; upgrade rather than working around cache serialization.
• Auth middleware: a 403 with Authorize enabled usually means the Chronos provider/config was not published. Check provider registration before debugging policies.
• Older published config: new config keys work even if the config was published by an older version, but clear config cache after upgrade and review the file for clarity.
• No migrations: 1.9.1 adds no migrations, so deployment only needs Composer update, config review, and cache clear.
• Dependency constraint: illuminate/support now requires ^10.0|^11.0|^12.0|^13.0; Laravel 9 apps must stay on an older Chronos release.