Cron Manager Laravel Laravel Package

Getting Started

v1.0.0 is the first tagged release, and the release notes contain only a changelog link — no documented features, breaking changes, or migration path. Treat the source and README as the source of truth, and expect to spend the first 15 minutes reading src/ rather than the docs.

Minimal steps:

1. composer require zpm-packages/cron-manager-laravel (pin to ^1.0 — see Gotchas).
2. Publish assets: php artisan vendor:publish --provider="Zpm\CronManager\CronManagerServiceProvider" and check what lands in config/ and database/migrations/.
3. php artisan migrate — inspect the published migration first if you already have a cron_jobs-style table.
4. Confirm the package registers its own scheduler hook. Check src/CronManagerServiceProvider.php for a Schedule/schedule:run integration or a bootstrapped Kernel::schedule override; if it does not, you will need one line in routes/console.php or app/Console/Kernel.php.

Where to look first, in order: config/cron-manager.php (all the quirks live here), the service provider (what it auto-registers), src/Console/ (artisan surface), then the routes/controllers if there is a UI.

First real use case: take one existing hardcoded $schedule->command('reports:prune')->daily(); and move it into the manager. That single migration exercises config, storage, execution, and logging end-to-end and tells you whether the package is worth adopting more broadly.

Implementation Patterns

Dashboard-defined vs code-defined. Most cron managers let entries live in the database, edited at runtime without a deploy. Use that deliberately: keep business-critical schedules (billing, digests) in code where they are reviewed and version-controlled, and reserve DB-managed entries for operational jobs (cache warming, ad-hoc cleanups) that ops needs to tune without a release. Mixing the two without a convention is how you end up with a "who disabled the invoice job?" incident.

Wrap, don't rewrite. Point managed entries at existing artisan commands or invokable jobs rather than porting logic into package-specific job classes. That keeps the package replaceable — you can rip it out and go back to $schedule->command() in an afternoon.

One scheduler, many entries. Laravel still needs a single system crontab line (* * * * * php artisan schedule:run). The manager sits above that; it does not replace it. Verify this on the server early, because a working UI with a dead system cron is the classic silent failure.

Overlap and concurrency. For anything that can exceed its interval, set withoutOverlapping() and an expiry matched to realistic runtimes, not the schedule frequency. On multi-server deployments pair this with onOneServer() — which requires a shared cache driver (Redis, database, memcached), not array or file.

Deploy workflow. If entries are DB-backed, seed them from a migration or seeder so staging and production converge. Never hand-edit production rows as the deployment mechanism; you will lose them on the next environment rebuild.

Observability. Route the manager's execution log into your existing stack rather than reading it in the UI. If it fires events or writes a log table, hook that into your alerting so a failed prune does not sit unnoticed for a week.

Gotchas and Tips

• Empty release notes are a red flag, not a formality. Pin "zpm-packages/cron-manager-laravel": "^1.0.0" and read CHANGELOG.md before every minor bump until the project demonstrates a documentation habit. A 1.0.0 tag with no described API surface means the surface may still move.
• Timezone drift. Confirm whether schedule evaluation uses config('app.timezone') or the server's. A manager UI that displays local times but evaluates in UTC produces offsets that look like bugs in your job.
• withoutOverlapping expiry is not a safety net. If a job hangs past the lock TTL it will be re-entered while the first instance is still running. Set the expiry generously and make jobs idempotent.
• Lock driver mismatch. onOneServer() on file or array cache silently degrades to per-server locks. Check CACHE_STORE before trusting the checkbox.
• Published migrations. Some packages ship migrations that assume a clean schema. Read the file before running it, and check for a published create_ filename collision if you re-publish.
• UI authorization. If the package registers routes, verify the middleware. Dashboards that let anyone toggle cron jobs are a privilege-escalation surface; wrap the route group in your auth + an admin gate.
• Debugging. Use php artisan schedule:list to confirm what Laravel actually sees, and php artisan schedule:test to run a single entry in isolation. If the manager bypasses Laravel's scheduler entirely and runs its own loop, those commands will not reflect managed entries — a quick way to tell which architecture you are dealing with.
• Extension points to check for: a job-type registry or interface for custom runnables, events around execution (useful for metrics), and a config toggle to disable the built-in UI in production.