Health Check Bundle Laravel Package

Product Decisions This Supports

• Reliability / uptime roadmap: v1.1.0 now ships distinct /ping (liveness) and /ready (readiness) endpoints, which maps cleanly onto Kubernetes probe semantics and load-balancer health checks. The decision shifts from "can we get any signal" to "do we gate traffic on readiness or liveness" — a question you can now answer with the package rather than around it.
• Deployment model decisions: the /ready endpoint plus health-check groups means you can express partial readiness (e.g., "DB is up but a downstream dependency is degraded"). That is the difference between a deploy gate you can trust during canary and a boolean that flaps. Choose the grouping taxonomy deliberately now, because it becomes the contract your rollout tooling depends on.
• Build vs. buy: the build side just got slightly cheaper to argue and slightly harder to dismiss. In-house is still ~0.5–2 engineer-days for a basic endpoint, but the package now covers multi-connection DB checks, groups, deduplicated execution, and per-check timing — closer to 3–5 engineer-days of parity work. Buy still only wins if the Symfony packaging burden is near zero, which for a Laravel stack it is not.
• Incident response and triage: performance statistics per check plus the in-memory cache fix (no double execution) make the JSON payload genuinely usable for MTTR reduction — on-call can see which dependency is slow versus down. This resolves the earlier "verify it isn't boolean-only" open question in the package's favor.
• Observability and capacity planning: per-check timings are a lightweight latency signal for dependencies. Not a replacement for APM, but useful as a cheap early-warning feed into dashboards, and a reasonable input to SLO reporting on dependency responsiveness.
• Procurement / enterprise readiness: the addition of SECURITY.md, CONTRIBUTING, CODE_OF_CONDUCT, CI workflows, and PHPStan level 9 moves this from "no hygiene signal" to "some hygiene signal." That is still a long way from SBOM or signed releases, but it changes the conversation in a vendor review from "why is this here" to "what's the maintenance plan."
• Ecosystem mismatch remains the decision input: still published as a bundle, still Symfony DI/console conventions. The feature growth does not change the port-versus-replace framing — it only raises the value of the port if you decide to do one.

When to Consider This Package

Consider it only if all of the following hold:

• You are on Symfony (or deliberately porting), since "bundle" still implies Symfony DI/console conventions rather than a Laravel service provider.
• You need probe endpoints this sprint and the alternative is slipping a platform milestone. v1.1.0's /ping and /ready are exactly the shapes Kubernetes and most load balancers expect, which removes the "write the routing yourself" step.
• You need multi-database or grouped dependency checks — this is now a real differentiator versus rolling your own, and the grouping model is the part most in-house implementations get wrong first.
• You are comfortable pinning the version, vendoring or forking, and assigning a named internal owner. The CI, community files, and PHPStan level 9 are encouraging but do not change the fundamentals: one maintainer, minimal adoption, no third-party security review.
• The check surface and output schema match what you need; inspect the source for the exact group semantics, since grouping behavior is a contract you will build alerting on top of.
• MIT license is compatible with your distribution model (it is, for essentially all commercial uses).

Look elsewhere when:

• You are on Laravel — use the framework's built-in health route (Laravel 11+), spatie/laravel-health, or ohdearapp/health-check. This release does not narrow that gap; it widens the feature gap and therefore the temptation to port, which is a cost, not a benefit.
• You need audited supply-chain provenance (SOC 2 / ISO 27001 vendor diligence, SBOM, signed releases). SECURITY.md is a disclosure policy, not an audit.
• You need deep or custom checks — replica lag per shard, queue depth per tenant, third-party API budgets, feature-flag-dependent readiness. Groups help you organize these but you still write the checks.
• You need multi-service aggregation or a hosted status page; buy a monitoring product instead.
• The endpoint is internet-exposed. /ping and /ready are additional unauthenticated-by-default surfaces; confirm both can be bound to an internal listener or gated by auth before rollout.

How to Pitch It (Stakeholders)

To executives: This release materially improves a small, MIT-licensed infrastructure component: it now provides standard liveness and readiness probes, grouped and multi-database checks, and per-check timing, with CI and static analysis at PHPStan level 9. That is real engineering maturity for a project this young. What has not changed is adoption — still a single maintainer and effectively no dependent base — so it remains unsuitable as a dependency of record. Recommendation: extend the timeboxed spike to two days to evaluate the new probe and grouping features, keep it behind an internal HealthCheck interface, and hold the default of a native implementation unless the spike shows savings that survive a port.

To engineering: The new /ping and /ready endpoints, health-check groups, and multi-connection DB support are precisely the features you would otherwise hand-roll, and the in-memory cache fix removes a real correctness bug (double-executed checks) you would likely have reproduced. The performance stats are a cheap latency signal worth wiring into dashboards. Constraints are unchanged: Symfony packaging in a Laravel codebase, one maintainer, no community validation. The new CI and SECURITY.md reduce — but do not eliminate — the "abandoned in six months" risk. Mitigations stay the same and stay cheap: pin, vendor, wrap behind an interface, keep an in-house fallback.

Bottom line: Still do not adopt as-is for a Laravel stack. The release upgrades this from "reference implementation" to "credible reference implementation with a port cost worth measuring" — validate in a two-day spike, plan to replace, and only port the grouping and probe-routing ideas if the spike justifies it.