Laravel Health Check Laravel Package

Product Decisions This Supports

• Build vs. buy for service health endpoints. This package replaces a hand-rolled /health controller with a maintained, configurable set of checks (database, cache, queue, storage, and similar dependencies) exposed as a machine-readable endpoint. The PM decision is whether a custom endpoint is worth owning; for most teams it is not.
• Reliability and SLO roadmap. A standardized health endpoint is the prerequisite for meaningful uptime monitoring, status pages, and error-budget reporting. Adopting it turns "is the app up?" into a measurable, alertable signal without standing up a separate observability stack.
• Deployment and infrastructure gating. JSON health output is directly consumable by Kubernetes liveness/readiness probes, load balancer target-group checks, and CI/CD post-deploy smoke tests. This supports decisions about canary releases, blue/green cutovers, and automated rollback triggers.
• Incident response and MTTR. A single endpoint that reports which dependency failed (DB vs. cache vs. queue) shortens triage and reduces escalation noise. It supports the decision to invest in faster diagnosis rather than more alerting.
• Platform upgrade sequencing (new in v3.0.0). The release raises the floor to Laravel 12+ and PHP 8.2+, and adds Laravel 13 / PHP 8.5 support. This makes the package a forcing function in the upgrade roadmap: any team still on Laravel 11 or PHP 8.1 is now pinned to v2.1.x and accumulating unmaintained dependencies.
• Vendor and lock-in posture. Self-hosted, no SaaS contract, no per-seat or per-check pricing, and no data leaving the infrastructure. Relevant wherever procurement or data-residency review is a gate.

When to Consider Adoption

Adopt when:

• The application runs Laravel 12 or 13 on PHP 8.2+ — after v3.0.0 this is a hard requirement, not a preference.
• You operate behind a load balancer, Kubernetes, or an autoscaling group that needs a probe endpoint, or you pay for external uptime monitoring that needs a target.
• You want dependency-level health signal (DB, cache, queue, storage) rather than a bare 200 OK from /.
• The team is small enough that a maintained package beats an in-house controller, and you want the health contract to be consistent across multiple Laravel services.
• You need an auditable, self-hosted monitoring surface — regulated or on-prem environments where SaaS probes are not viable.

Look elsewhere or defer when:

• You are on Laravel 11 or earlier, or PHP < 8.2. v3.0.0 is not installable; staying on v2.1.x is a deliberate, time-boxed decision that needs an owner and an exit date.
• Your need is deep APM, distributed tracing, or log aggregation — this package reports health status, not performance or request-level telemetry. Pair it with a real observability tool rather than substituting for one.
• You need hosted dashboards, on-call scheduling, and alert routing. This package produces the signal; it does not page anyone.
• You have non-Laravel services in the estate and require one uniform health protocol across languages.
• You already run a platform-standard health framework (e.g., an internal golden-path template). Duplicating it fragmentates the contract.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost reliability upgrade. A maintained open-source package gives every Laravel service a single, standard "is this working?" endpoint that our load balancers, Kubernetes probes, and monitoring tools can all read the same way. It reduces mean-time-to-diagnose during incidents, removes custom code we would otherwise own and maintain forever, and carries no licence cost or vendor lock-in. The v3.0.0 release adds support for Laravel 13 and PHP 8.5 — it keeps us current rather than adding work.

The one thing to decide: v3.0.0 drops Laravel 11 and PHP 8.1. Teams on those versions cannot upgrade and will fall behind on fixes. I recommend we confirm our Laravel/PHP versions this quarter and, if any service is below the floor, schedule its framework upgrade — that upgrade is the real cost here, not the package.

For engineering: v3.0.0 is a support-matrix release, not a feature release. Changes are: added Laravel 13 and PHP 8.5 support; removed Laravel <12 and PHP <8.2. There is no migration work beyond the version floors — but it is a major-version bump, so treat it as a coordinated upgrade, not a patch. Pin to v2.1.x on anything that cannot yet meet the floor, track those pins as technical debt, and verify our health endpoint contract (route path, response shape, status codes) is covered by a smoke test before rollout so probe configuration does not silently break.