Weave Code
Laravel Healthchecks Laravel Package
renoki-co/laravel-healthchecks
Laravel Healthchecks adds configurable health-check endpoints to your Laravel app, letting you monitor database, cache, storage, queue, and custom checks through simple HTTP responses for uptime and readiness probes.
Laravel Healthchecks is a simple controller class that helps you build your own healthchecks endpoint without issues.
Frequently asked questions about Laravel Healthchecks
- How do I install renoki-co/laravel-healthchecks in a Laravel app?
- Install it with composer require renoki-co/laravel-healthchecks and the package service provider will be auto-discovered. Publish the config file with php artisan vendor:publish so you can list the checks you want the endpoint to run. The package registers the health route for you, so there is no controller code to write. Total setup is a composer require, a config publish, and enabling the checks your service needs.
- Which Laravel and PHP versions does laravel-healthchecks support?
- Version 2.1.0 supports Laravel 8.x and 9.x on PHP 8.0 or higher, with PHP 8.0.2+ required if you are on Laravel 9. The older 2.0.x line is the only option for Laravel 7.x applications or apps still running PHP 7.3 and 7.4. Check your locked dependency graph with composer why-not before assuming a constraint set resolves. Applications on Laravel 7 stay pinned to 2.0.x and will not receive further upgrades.
- What health checks does Laravel Healthchecks include out of the box?
- The package ships pluggable checks for the common Laravel dependencies: database connectivity, cache, Redis, storage, and queue. Each check is enabled through the config file and aggregated into a single HTTP response. You can enable only the checks that are meaningful for a given service rather than turning everything on. That keeps the endpoint fast and avoids failing readiness for a dependency the service does not actually use.
- How do I add a custom health check to the endpoint?
- Custom checks are registered as closures in the package config, so you can express any condition your service depends on. A closure typically returns a boolean or throws when the dependency is unhealthy, and the result rolls into the aggregate response. This is the right place for things like a critical third-party API ping or a feature-flag service check. Keep custom closures cheap, because they run on every probe hit.
- Can I use Laravel Healthchecks for Kubernetes liveness and readiness probes?
- Yes, it is a natural fit for kubelet probes, load balancer target group checks, and external uptime monitors. The recommended pattern is a shallow liveness endpoint that only proves the PHP process is serving, plus a deeper readiness endpoint that runs the database and cache checks. Sharing one deep endpoint for both probes can cause the kubelet to restart pods during a transient database outage. Configure separate routes and checks so liveness stays cheap and dependency-free.
- Is the healthcheck endpoint secure by default?
- The endpoint is unauthenticated by default, which is intentional so probes and load balancers can reach it without credentials. That also means it can disclose which dependencies your service uses and whether they are currently reachable. Keep it inside the cluster network or behind a middleware, network policy, or ingress rule rather than exposing it to the public internet. If an external monitor needs access, restrict it by IP and consider a shallow check only.
- Will health checks slow down my app or add load during an outage?
- Checks that hit the database, cache, or Redis run on every probe, so they add a small amount of load at your probe interval. During a partial outage, a deep endpoint can amplify pressure on an already struggling dependency, especially with aggressive probe intervals and short timeouts. Keep the check set minimal and set a timeout budget that reflects what you actually need to know. Many teams pair a cheap liveness route with a deeper readiness route hit less frequently.
- How do I test the healthcheck endpoint in my Laravel test suite?
- Because the package exposes a normal Laravel route, you can cover it with a standard feature test that calls the endpoint and asserts the HTTP status and JSON body. Assert the healthy case as well as the failure case by pointing a check at an unreachable dependency. This guards against a config change silently disabling a critical check. A feature test also catches route or middleware regressions during framework upgrades.
- What are the alternatives to laravel-healthchecks?
- Spatie's Laravel Health offers a broader set of checks plus scheduling and notifications, and is a good pick if you want historical results rather than a single endpoint. Laravel's own lightweight health route in recent skeletons covers the trivial is-the-app-booting case with no dependencies. For deep dependency checks with alerting, an external uptime service may be simpler than adding a package. Choose based on whether you need a probe endpoint, a monitoring platform, or both.
- Is laravel-healthchecks actively maintained and how do I upgrade from 2.0.x to 2.1.0?
- It is a community-maintained package, so treat the support window as an explicit judgment call rather than an assumption and confirm whether 2.0.x is still receiving fixes. Release 2.1.0 is a compatibility-narrowing release that adds Laravel 9 support while dropping PHP 7.3, PHP 7.4, and Laravel 7.x. On an eligible app the upgrade is a version bump with no documented config-breaking changes, followed by a regression pass on the endpoint. Apps on Laravel 7 or PHP 7.4 must stay on 2.0.x until the framework and PHP upgrades land.
Weaver
How can I help you explore Laravel packages today?