Bundle Health Check Laravel Package

Product Decisions This Supports

• Platform upgrade (Symfony 7.4) unblocked. The headline change is an expanded Symfony compatibility constraint. If we are planning or currently executing a Symfony 7.4 upgrade, this release removes a dependency-level blocker — that is a roadmap-enabling change, not a feature.
• Safe, low-ceremony patch adoption. 2.3.2 → 2.3.3 is a patch release with no breaking changes, no deprecations, and no API surface changes. Existing ^2.3 constraints pick it up without code review beyond a smoke test.
• Observability / uptime investment. A health-check bundle underpins readiness/liveness probes, load-balancer target health, and dependency-status dashboards. This is the kind of package that supports SLO/reliability workstreams and incident response rather than end-user features.
• Build vs. buy. Reinforces "buy/consume" for health endpoints: the cost of maintaining our own health-check controllers and probe contracts is higher than tracking a maintained bundle.
• Vendor-risk signal, positive but thin. The release also replaces a hardcoded Sonar host URL with a secret reference in their own CI — good hygiene on their side, zero impact on consumers, but evidence the project is actively maintained. Weighed against a single new contributor and a two-PR release cadence, this is maintained, not heavily resourced.
• Not a differentiator. Nothing here changes competitive positioning or customer-facing capability; treat it as maintenance/plumbing.

When to Consider This Package

Consider it when:

• We run a Symfony application (this is a Symfony bundle — it is not Laravel-native; if the target app is Laravel, evaluate spatie/laravel-health or an equivalent first).
• We need standardised HTTP health/readiness endpoints consumed by Kubernetes probes, an ALB/NLB target group, or an uptime monitor, and we don't want to hand-roll per-service controllers.
• We want health checks to aggregate dependency status (DB, cache, external services) behind a stable contract instead of bespoke per-team endpoints.
• We are on, or moving toward, Symfony 7.4 — 2.3.3 is the version that declares that support.
• We value patch-level stability over feature velocity for infrastructure code.

Look elsewhere when:

• The stack is Laravel — framework mismatch makes this a poor fit regardless of quality.
• We need a rich, pluggable health framework with many pre-built checks, retry policies, or notification integrations; this is a focused bundle, and broader ecosystems may fit better.
• We require enterprise support SLAs, LTS guarantees, or a deep maintainer bench — the contributor base visible in this release is small.
• We only need a single trivial /health 200 response; a five-line controller may be genuinely cheaper than a dependency.

How to Pitch It (Stakeholders)

For executives (one line): A small patch release to our health-check dependency that keeps us compatible with the upcoming Symfony 7.4 upgrade — low risk, adopt on the normal cadence, no budget or headcount ask.

For engineering leadership: Version 2.3.3 is a maintenance release. It adds Symfony 7.4 to the supported matrix, which decouples our framework upgrade plan from this dependency, and it fixes a hardcoded CI secret reference in the upstream project — a maintainer-hygiene fix with no effect on our code. There are no breaking changes, no deprecations, and no new APIs, so the upgrade is a routine composer update plus a probe smoke test in staging. One caveat worth naming: this is a Symfony bundle, not a Laravel package, so it only applies if the target service is Symfony; and the upstream project is actively but thinly maintained (single new contributor in this release), so we should keep our integration shallow and pinned to ^2.3. Recommendation: adopt now on the standard patch cadence, verify /health and readiness responses in staging, and revisit the build-vs-buy question only if the project shows signs of going dormant.