Laravel Health Check Laravel Package

Product Decisions This Supports

• Feature: deployment safety and operational readiness. The package exposes health/readiness endpoints that orchestration platforms (Kubernetes, ECS, load balancers) and uptime monitors can poll. This is what makes zero-downtime deploys, rolling restarts, and autoscaling decisions safe rather than aspirational — traffic only routes to instances that report healthy.
• Feature: dependency-aware status reporting. Rather than a trivial "app is up" ping, it lets us assert on the things that actually break production — database connectivity, cache/Redis, queue workers, disk space, external APIs — and surface them through a single contract.
• Roadmap input: framework and runtime upgrade sequencing. v3.0.0 targets Laravel 13 and PHP 8.5, and drops Laravel <12 and PHP <8.2. Because the package's major version is now coupled to the framework major, the platform-upgrade roadmap and this dependency's roadmap must move together. Any Laravel 12→13 migration plan should include a line item for this package.
• Build vs buy: buy, and the margin is now clearer. A competent engineer can write a /health route in an hour. Writing one that checks N dependencies, degrades gracefully, returns correct status codes, is configurable per environment, and is maintained across framework majors is a recurring cost. This package is a well-scoped, single-purpose dependency that removes that recurring cost.
• Use cases to evaluate against: public-facing status pages, incident triage ("is it the DB or the app?"), pre-deploy smoke tests in CI, and synthetic monitoring from an external prober.
• Risk signal: support-policy alignment. The maintainers dropping versions that no longer receive security fixes is the right call, and it means our own support window is the binding constraint, not theirs.

When to Consider This Package

Adopt when:

• We are on Laravel 12 or 13 and PHP 8.2+. This is now a hard floor — v3.0.0 will not install below it.
• We deploy to a container orchestrator or behind a load balancer that needs liveness/readiness signals.
• We want more than a single boolean health signal, and want to add custom checks (a payment provider, an internal service) without building a framework.
• We want an actively maintained dependency rather than an in-house route that quietly rots.

Look elsewhere — or stay on v2.1.1 — when:

• We are pinned to Laravel 11 or earlier, or PHP 8.1 or below. v2.1.1 remains the correct pin; do not force the upgrade. Note that staying there means forgoing future fixes, so this should have an owner and a review date.
• We already run a full observability stack (Datadog, New Relic, OpenTelemetry) whose agents already answer "is this instance healthy." Adding a second source of truth creates ambiguity about which signal drives routing.
• We need rich telemetry, historical metrics, or alerting. This package answers "healthy or not" at a point in time; it is not a monitoring system, and should not be pitched as one.
• The managed platform already provides equivalent probes (some PaaS offerings do), making the package redundant.
• Health checks are the only thing needed and the team would rather own ten lines of code than a dependency. Legitimate, but budget for maintenance across framework upgrades.

Upgrade guidance: v3.0.0 is a coordinated breaking release. Treat it as a coupled upgrade with the Laravel/PHP bump, not a standalone composer update. Pin explicitly, verify each registered check in staging (a check that silently passes is worse than no check), and confirm nothing in our config references removed support paths.

How to Pitch It (Stakeholders)

For executives — one paragraph: We depend on an open-source package that gives our platform a reliable "am I healthy?" signal. Orchestrators and load balancers use it to decide whether to send traffic to an instance, which is what allows us to deploy without downtime and recover automatically from bad instances. Its new major release aligns with our Laravel 13 / PHP 8.5 direction and drops versions that no longer receive security fixes — good hygiene, and it means our upgrade windows now move in lockstep. Cost is a small amount of engineering time inside an upgrade we were already planning.

For engineering leads: v3.0.0 is a breaking change on two axes — Laravel <12 and PHP <8.2 are no longer supported. That aligns with upstream security policy and is the right boundary. Practically: sequence this with the framework upgrade, don't split it into a separate PR; pin the version; and re-verify every registered health check after the bump, because a health endpoint that returns 200 while a dependency is down is a silent failure mode. If any service is stuck on Laravel 11 or PHP 8.1, keep it on v2.1.1 and give that service an owner and a migration date.

For the product narrative: this is unglamorous infrastructure that converts "we deploy carefully and hope" into "we deploy and the platform tells us whether it worked." It is cheap, single-purpose, and now explicitly maintained against the framework versions we intend to run.