Download the PHP package cronalive/laravel without Composer

cronalive/laravel

Heartbeat monitoring for Laravel scheduled jobs with CronAlive: if a job stops pinging on schedule, you get an alert.

Pings never throw — monitoring must not break the monitored job.

Requirements

Every supported version is covered by the same integration suite in CI — scheduler macros, signal timeouts and the swallowing of a dead ping domain are asserted against a real framework of each major, not against mocks.

A note on Laravel 10: it is past its security-fix window upstream, and we support it because real projects still run it — not as a recommendation. Upgrading is the safer place to be.

Install

Set the env (only needed for slug addressing / auto-provisioning):

Usage

Both scheduler macros send /start before the job and success / /fail after it, so CronAlive also measures the job duration. The success ping goes out only when the job exits with 0; a failed job sends /fail and nothing else.

The schedule comes from your code

pingCronaliveSlug reads the schedule off the scheduled task itself and sends it along with the first ping, so an auto-provisioned check knows when to expect the job — no retyping the schedule in the dashboard, and no way for the two to drift apart.

The timezone is the task's own if it has one, otherwise your app.timezone. Without graceSec the project default applies (Projects → Auto-provisioning in the dashboard). The shortest grace CronAlive accepts is 30 seconds — pass less and it is raised to 30 rather than refused, since schedulers start jobs with a few seconds of jitter and a shorter grace turns that jitter into false alerts.

Sub-minute tasks. everyThirtySeconds() and friends leave the cron expression at * * * * * and keep the real interval elsewhere, so they travel as period. CronAlive's shortest period is 60 seconds, so anything faster is monitored as "pings at least once a minute" — true for such a job, and it never false-alarms.

Grace is a named argument on purpose. The second positional parameter is still $create, because pingCronaliveSlug('etl-run', false) already means "do not create the check" in existing code — reordering would silently turn that into "create it with a zero grace period".

Tags are labels for grouping checks on the dashboard: up to 20 of them, up to 64 characters each. The server corrects rather than rejects — blanks dropped, long ones truncated, extras past the twentieth discarded — because a label is not worth failing a ping over.

Creating is not updating. Schedule parameters apply only when the check is created. Once it exists, further pings just count — the parameters are ignored, deliberately and silently, so a deploy can never rewrite a schedule someone tuned in the dashboard. Changed the schedule in code? Update the check in the dashboard (or via the API), or delete it and let the next ping recreate it.

One more thing worth knowing: ->when() / ->skip() filters stop the task and its pings, so a skipped run looks exactly like a missed one. Pause the check while it is expected to be skipped, or drive the condition inside the job instead.

IDE support

The macros are attached to Illuminate\Console\Scheduling\Event at runtime, so static analysis cannot see them and your IDE will flag pingCronalive / pingCronaliveSlug as "method not found". The package ships _ide_helper.php with the signatures; point your IDE at it once — in PhpStorm, right-click the file inside vendor/cronalive/laravel and choose Include to Project. The file is never executed (its class sits behind if (false)) and is not autoloaded.

Pings never hold your schedule

The macros do not use Laravel's pingBefore / thenPing / pingOnFailure. Those callbacks swallow errors, but they wait on Laravel's default scheduler client — 10 s to connect, 30 s in total, per signal, so up to 90 s for a job with three of them (and no bound at all if your app binds its own Guzzle client into the container). Scheduler callbacks run inline, one after another, so an unreachable ping domain does not just delay one job — it shifts everything scheduled behind it.

Every signal is sent with connectTimeout(2) and timeout(5) instead, and a failure is swallowed: the signal either goes out fast or is quietly dropped. There is no retry inside a signal — it would only double the delay, and the next scheduled run sends a fresh ping anyway.

A dropped signal is still reported through your exception handler, so it shows up in the log, but at most once per schedule:run — a dead domain would otherwise write the same trace for every signal of every job.

Docs

Full documentation: https://cronalive.com/docs/.

License

MIT