Weave Code
Laravel Heartbeat Laravel Package
exolnet/laravel-heartbeat
A lightweight heartbeat endpoint for Laravel apps, exposing a route that confirms your application and scheduler are alive so external monitors can alert you when cron jobs or queued work stop running.
Periodically schedule a job to send a heartbeat to a monitoring system.
Frequently asked questions about Laravel Heartbeat
- What does the exolnet/laravel-heartbeat package actually do?
- It gives your Laravel application a small heartbeat mechanism: a route that confirms the app is alive and a scheduled job that periodically pings an external monitoring system. Because the job runs through Laravel's scheduler, a missing heartbeat tells you that cron or queued work has stopped. It is intentionally lightweight, meant as an operational signal rather than a full observability platform.
- How do I install exolnet/laravel-heartbeat in a Laravel application?
- Install it with Composer using an explicit constraint such as ^1.15 for Laravel 12 applications, or ^1.14 if you are still on Laravel 11. Then publish any package configuration if the package provides it and confirm the heartbeat route is registered by your service provider. Run php artisan route:list to verify the endpoint before wiring it into your monitor.
- Which Laravel versions are supported by exolnet/laravel-heartbeat v1.15.0?
- Version 1.15.0 is a compatibility-matrix release: it drops Laravel 11 and Testbench 9 support and aligns the test matrix with Laravel 12 and the matching Testbench line. Treat it as Laravel 12+ oriented unless the composer.json constraints say otherwise. Always check the exact PHP, Laravel, and Testbench requirements in the package's composer.json before upgrading.
- Why does Composer fail to install exolnet/laravel-heartbeat v1.15.0 on Laravel 11?
- Because v1.15.0 no longer declares support for Laravel 11 or Testbench 9, so dependency resolution can fail against a Laravel 11 lock file. The documented path for Laravel 11 consumers is to pin to ^1.14.x and defer v1.15.0 until the host application is upgraded. Avoid floating constraints like * if you need to stay on Laravel 11, since a future release could silently change eligibility.
- How do I schedule the heartbeat job in Laravel?
- Register the package's heartbeat command or job in your scheduler, either in routes/console.php or in the console kernel depending on your Laravel version. Make sure the schedule frequency is shorter than the grace period configured in your external monitor, otherwise you will get false alerts. After deploying, run php artisan schedule:list to confirm the entry is registered and check that cron is invoking schedule:run every minute.
- How should I secure the heartbeat route in production?
- Treat the endpoint as a public health check that external monitors can reach, not as an authenticated API. Review the package's published configuration for the route path, middleware, and any token or secret option, then apply your own middleware group or IP allowlist if your monitor supports it. Keep the response minimal so it does not leak application internals or environment details.
- Can I use laravel-heartbeat instead of a full observability platform?
- It replaces only the uptime and scheduler-liveness slice of a broader platform, not error tracking, tracing, or metrics. It is a good fit for monoliths, API services, and scheduled workers that want a Laravel-native signal without adding a heavier dependency. Many teams run it alongside something like Sentry or a hosted monitor rather than instead of one.
- How do I test the heartbeat endpoint and the scheduled job in Laravel?
- Add a feature test that issues a GET request to the configured heartbeat route and asserts a successful response, so route registration and middleware regressions are caught in CI. For the scheduler side, run php artisan schedule:run in a test or staging environment and confirm the heartbeat reaches your monitor or a faked HTTP endpoint. Mirror the package's supported Laravel and PHP matrix in your own CI pipeline to avoid version drift.
- Does the package work with route and config caching in production?
- The package integrates through standard Laravel service provider and route registration, so it should behave like other framework routes under route:cache and config:cache. Still, validate it in staging by running php artisan optimize and then hitting the heartbeat URL, since cached routes and config can expose registration or middleware issues that do not appear locally. Include that check in your deployment checklist whenever you upgrade the package.
- Is exolnet/laravel-heartbeat actively maintained, and what should I watch for?
- The project appears actively maintained, with releases that explicitly align its test matrix to supported Laravel versions. The trade-off is that it will drop older framework versions, as v1.15.0 did with Laravel 11, so track Laravel's lifecycle alongside package releases. Pin an explicit constraint, review release notes before upgrading, and keep an eye on your internal CI matrix so it matches the package's supported platform.
Weaver
How can I help you explore Laravel packages today?