- How do I install cron-monitor/php-sdk in a Laravel application?
- Run composer require cron-monitor/php-sdk, then publish the package config so a config/cron-monitor.php file exists. Laravel package auto-discovery registers the service provider automatically. If your app uses extra.laravel.dont-discover, register the provider manually in bootstrap/providers.php on Laravel 11 or config/app.php on Laravel 10.
- Which PHP and Laravel versions does cron-monitor/php-sdk support?
- The SDK requires PHP 8.2 or newer and ext-curl, unless you bind a PSR-18 HTTP client yourself. It is documented against Laravel 10 and 11, and because it is a thin framework-agnostic HTTP client it also works in non-Laravel PHP projects. There is no scheduler, storage, or queue dependency to satisfy.
- How do I attach heartbeat monitoring to a Laravel scheduled task?
- Chain the monitor macro onto an existing scheduler entry, for example ->monitor(config('cron-monitor.monitors')['reports:nightly'] ?? ''). The SDK then emits a start signal, followed by a success or fail signal when the run finishes. You only touch the schedule definition; the job class, queue topology, and deploy shape stay unchanged.
- Does cron-monitor/php-sdk break my cron job if cronheart.com is down or the network fails?
- No. The client is explicitly fail-open: it never throws and never breaks the job, using a 5 second timeout and a single retry. The trade-off is silent degradation, where a bad network path or a wrong monitor UUID produces a missing heartbeat rather than an application error. That is only safe if dead-man's-switch alerting on missing pings is configured and tested on the cronheart.com side.
- Do I need CRON_MONITOR_API_KEY, or just the monitor UUID?
- Heartbeat pings need only the per-monitor UUID, which acts as a scoped write credential. The cmk_ API token is account-wide and is only relevant to management operations such as cron-monitor:sync, so keep that separation explicit rather than handing the account token to every runtime. Store both in a secret manager where possible, and note two footguns: an empty CRON_MONITOR_API_KEY= in .env is transmitted as an empty bearer token, and the attribute form reads process env directly, so it can break under config:cache.
- How do I monitor queue jobs that run outside the scheduler?
- Use the middleware the SDK ships for queued jobs, which lets you report runs that never pass through the Laravel scheduler. This keeps coverage on dispatch-heavy workloads without editing job logic. Apply it per job rather than globally so you do not add an HTTP call to every queue worker task.
- Can I use cron-monitor/php-sdk without Laravel, in a plain PHP project?
- Yes. The package is a framework-agnostic HTTP client whose only job is emitting start, success, and fail signals to an endpoint that defaults to cronheart.com. Outside Laravel you call the client directly instead of relying on the service provider and the scheduler macro. The PHP 8.2 and ext-curl requirements still apply.
- How do I test that heartbeats are being sent without pinging production?
- Bind a fake PSR-18 client in your test container so outgoing heartbeat requests are captured instead of sent to cronheart.com. You can then assert that a start, success, or fail signal is emitted for each monitored schedule entry. For a quick manual check, confirm the macro is registered with php artisan list cron-monitor and inspect resolved values with php artisan debug:config cron_monitor.
- What does php artisan cron-monitor:sync do, and is it safe to run in a deploy pipeline?
- The sync command reconciles your config entries with monitors on cronheart.com through the REST API, which requires an API-enabled plan and the account-level token. Because monitors are matched by name, renaming a scheduled job silently creates a second monitor and orphans the original. Idempotency and concurrent-run safety are not documented, so verify behaviour before wiring it into deploys rather than assuming it is safe.
- Is cron-monitor/php-sdk actively maintained, and what are the alternatives?
- It is an MIT-licensed client with a single maintainer, zero stars, and no dependents, and the backend it talks to is a closed commercial SaaS, so you can fork the client but not replace the server. Treat cronheart.com as a production dependency and confirm its uptime SLA, retention, and pricing tier before adopting. If third-party SaaS in the schedule runner is unacceptable, a self-hosted heartbeat service or an in-house dead-man's-switch gives you the same signal without vendor concentration.