Laravel Healthchecks Laravel Package

Technical Evaluation

Architecture fit renoki-co/laravel-healthchecks is a thin, opinionated Laravel package: a service provider, a config file, a route registration, and a set of pluggable "checks" (cache, database, Redis, queue, custom closures) that aggregate into a single HTTP health endpoint. It sits at the operational cross-cutting layer rather than the domain layer, so it does not constrain application architecture. That makes it a low-coupling fit for the standard Laravel service shape we run: one endpoint consumed by Kubernetes liveness/readiness probes, load balancer target-group health checks, or an external uptime monitor.

Integration feasibility Adoption is a composer require, a config publish, and a short list of checks. There is no schema change, no queue worker, no new infrastructure dependency beyond what the checks themselves touch. A single engineer can land it in a sprint, and it is reversible by removing the route. The main feasibility question is not "can we install it" but "which version line can each of our applications accept," which 2.1.0 has made materially more restrictive.

Technical risk Release 2.1.0 is a compatibility-narrowing release, not a feature release. It adds Laravel 9.x support but drops PHP 7.3 and 7.4 and drops Laravel 7.x. Concretely:

• Any application still on Laravel 7.x is pinned to the 2.0.x line and will receive no further upgrades.
• Any application on Laravel 8.x with PHP 7.4 can install 2.1.0 only after a PHP upgrade to 8.0+.
• Laravel 9 already requires PHP 8.0.2+, so the Laravel 9 support in this release is only reachable by teams that have completed the PHP 8 migration. Secondary risks: the endpoint is unauthenticated by default and can leak dependency topology if exposed beyond the cluster network; health checks that call the database or cache on every probe can amplify load during partial outages; and the package is community-maintained, so the 2.0.x support window is a judgment call we must make explicitly rather than assume.

Key questions

1. What is the actual fleet distribution of PHP and Laravel versions, and how many apps sit on Laravel 7.x or PHP 7.4?
2. Will 2.0.x continue to receive security fixes, and for how long? If not, what is our forced-upgrade deadline?
3. Who consumes the health endpoint today — kubelet, ALB/NLB, external monitor, or all three — and with what interval and timeout?
4. Which checks are required per service, and what is the acceptable latency budget for the endpoint under degraded conditions?
5. Does the endpoint sit behind network policy or auth, or is it internet-reachable?
6. Are we standardizing on liveness/readiness separation (shallow liveness, deep readiness), or a single endpoint for both?

Integration Approach

Stack fit Fits cleanly for services on PHP 8.0+ with Laravel 8.x or 9.x, deployed to Kubernetes or an auto-scaling group with target-group health checks. It is a poor fit for any service we intend to keep on Laravel 7.x long-term, since that service would be frozen on an unmaintained minor line.

Migration path Two tracks, decided per application by its PHP/Laravel baseline:

• Greenfield and PHP 8 / Laravel 8–9 apps: adopt 2.1.0 directly, constraint ^2.1.
• Laravel 7.x or PHP 7.4 apps: pin ^2.0 now, with a tracked work item to complete the PHP 8 and Laravel upgrade, then move to ^2.1. Do not attempt to hold 2.1.0 back on these apps; it will not resolve. No data migration, no config-breaking changes are documented in this release, so the upgrade from 2.0.x to 2.1.0 on an eligible app should be a version bump plus a regression pass on the endpoint.

Compatibility Verify against the application's locked dependency graph before committing: PHP >= 8.0 (8.0.2+ if Laravel 9), Laravel 8.x/9.x, and no conflict with pinned symfony/*, Guzzle, or Redis client versions. Run composer why-not on each candidate app rather than assuming the constraint set resolves.

Sequencing

1. Inventory PHP/Laravel versions across services; classify each as eligible or blocked.
2. Land 2.1.0 in one low-risk internal service first; validate route registration, config publish, and check behavior.
3. Define the probe contract: which checks run in liveness vs readiness, timeouts, and failure status codes.
4. Promote to staging with realistic probe intervals, then to production behind a canary.
5. Backfill remaining eligible services; file upgrade tickets for blocked ones.
6. Only after production validation, publish an internal usage standard so teams do not each invent their own check set.

Operational Impact

Maintenance Small dependency surface and infrequent releases, so ongoing maintenance is near zero between upgrades. The real maintenance cost is the version-matrix churn: each major Laravel and PHP release will produce another narrowing release like 2.1.0, and each one forces a fleet-wide audit. Budget for that audit as a recurring task rather than a one-off.

Support Community-maintained with no vendor SLA. We should record an internal decision on the minimum supported version line, identify an owner for the package relationship, and confirm the maintainer's policy on backporting fixes to 2.0.x. If 2.0.x goes unmaintained, Laravel 7.x apps inherit an unpatched dependency and that becomes a security-tracking item.

Scaling The endpoint is invoked once per pod per probe interval — with 30-second probes across a few hundred pods this is thousands of requests per hour, which is trivial for the HTTP layer but not for the checks behind it. Deep readiness checks that hit the database or Redis on every call will add measurable query load and can turn a slow dependency into a cluster-wide probe storm. Mitigations: enable result caching with a short TTL, keep liveness checks shallow and dependency-free, restrict deep checks to readiness, and set explicit timeouts below the probe timeout so the endpoint always answers.

Failure modes

• Misapplied probes: a deep readiness check wired to liveness causes every pod to restart when the database blips, converting a partial degradation into a full outage. This is the highest-severity failure mode and is a configuration error, not a package defect.
• False healthy: cached results or checks that swallow exceptions report 200 while a dependency is down, so orchestrators never drain the pod.
• False unhealthy: probe timeout shorter than check latency produces constant restarts under load.
• Cache-store dependency: if the caching used for results shares the store being checked, the health endpoint degrades exactly when it is most needed.
• Exposure: unauthenticated endpoint reachable outside the cluster leaks dependency inventory and internal names.
• Route collision: an existing /healthcheck route or middleware group silently shadows the package route.
• Version skew: a mixed fleet where some services are on 2.0.x produces inconsistent check semantics and on-call confusion.

Ramp-up Low for a Laravel developer — roughly half a day to install, configure, and validate, plus a day to design the probe contract. The non-obvious work is operational rather than technical: agreeing liveness vs readiness semantics, choosing checks that are cheap and meaningful, and writing a runbook entry so on-call knows that a failing health endpoint means "drain and investigate," not "restart." Plan a short knowledge-share for the on-call rotation as part of the rollout.