Symfony Health Check Bundle Laravel Package

Technical Evaluation

Architecture fit — poor for Laravel, and that is the headline. This is a Symfony bundle, not a Laravel package. It depends on Symfony's bundle registration model (bundles.php), the Bundle base class, DI compiler passes, autoconfiguration tags, and a Symfony routing/event kernel. Laravel consumes individual Symfony components (http-foundation, console, process, mime, etc.) but does not use FrameworkBundle or the bundle registration lifecycle. composer require would likely resolve, and then nothing would ever load. There is no service provider, no facade, no publishable config — none of the Laravel integration surface exists.

Integration feasibility — low to none as-is; moderate if treated as reference code. The capability (HTTP health/liveness endpoints probing DB, cache, disk, downstream services) is directly relevant to any Laravel estate. The implementation is not reusable without an adapter layer that would cost more than re-implementing. The package is small in scope by nature; health-check bundles are typically a few hundred lines. Bridging a 1-star, 0-dependent bundle into Laravel is a worse trade than writing 150 lines of Laravel-native checks or adopting a maintained package.

Technical risk — high. Signals stack badly: 1 star, 0 dependents, last release 2022-11-21, single maintainer. That means no downstream battle-testing, no community CVE surfacing, no evidence of PHP 8.3/8.4 or Symfony 7 support. A November 2022 release most likely constrains to PHP ~8.0/8.1 and Symfony 5.4/6.0 — Laravel 11/12 (PHP 8.2+, Symfony 7 components) is untested territory. Health endpoints are also a security-sensitive surface: they commonly leak DB connectivity, version strings, and environment metadata on an unauthenticated route. Unmaintained endpoint code carrying that exposure is a real, not theoretical, risk.

Key questions

• Is there an actual Symfony workload in the estate, or is this being evaluated purely because "health check" matched a Laravel need? If the latter, the evaluation is a category error.
• What is the driver — Kubernetes liveness/readiness probes, load-balancer checks, or uptime/alerting? The requirements differ materially (and a naive DB probe from 500 pods is its own outage vector).
• Has spatie/laravel-health (actively maintained, purpose-built for Laravel) been compared? It is the default answer unless there is a specific constraint.
• Version constraints on php and symfony/* — do they even admit the target Laravel version?
• If adopted, who owns the fork? Is there appetite to vendor and maintain, or does this become orphaned technical debt?
• Does the endpoint need auth, network restriction, or a split liveness/readiness contract before anything ships?

Integration Approach

Stack fit: mismatched framework, matched problem. Do not plan a direct integration into Laravel — it will not execute. Treat this package as (a) a candidate for genuine Symfony services only, or (b) a design reference for what checks and response shapes we want.

Recommended path — split by framework, standardize the contract.

• Define a framework-agnostic health contract first: response schema (status, checks[], duration), HTTP semantics (200 healthy / 503 unhealthy), liveness vs. readiness separation, auth/network policy.
• Laravel: adopt spatie/laravel-health or implement a small service provider with /health/live and /health/ready routes plus a check registry.
• Symfony (if applicable): this bundle is a candidate, subject to version-compatibility confirmation and a maintenance-risk sign-off.
• Align both on the same JSON shape so load balancers, k8s probes, and monitoring parse one contract.

Migration path. Greenfield — there is no prior state to migrate. If the organization already runs this bundle in Symfony, leave it in place and pin it; do not extend its footprint into Laravel.

Compatibility diligence before any commitment. Confirm the PHP constraint, the Symfony constraint, and whether the transitive symfony/* requirements conflict with the target Laravel release's pinned components. Composer resolution success is not evidence of runtime compatibility here — the bundle's boot path is never invoked by Laravel, so a clean composer install is a false positive.

Sequencing.

1. Confirm whether a Symfony workload exists (go/no-go gate).
2. Define the health contract and probe policy (auth, frequency, liveness vs. readiness).
3. Select implementations per framework; prefer maintained packages.
4. Wire into LB/k8s/alerting; add endpoint restrictions.
5. Add CI coverage so a dependency upgrade that breaks checks fails loudly rather than silently 404-ing.

Operational Impact

Maintenance — we would own it. Zero realistic upstream maintenance: lone maintainer, stale since 2022, no dependents. Adopting means forking, pinning, and absorbing PHP/Symfony upgrade work, security scanning, and bug fixes internally. The absolute cost is small (health checks are low-complexity code) but it is a recurring, permanent tax on a non-differentiating component.

Support — none. No vendor, no community triage velocity, no escalation path beyond a GitHub issue on a 1-star repo. Any incident rooted in this package is resolved by our own engineers reading the source.

Scaling — the probe pattern matters more than the package. Health endpoints themselves are cheap and per-instance. The scaling risk is architectural: a readiness check that queries the database on every probe, multiplied across an autoscaling fleet and a 5-second probe interval, becomes a meaningful load source on the primary. Worse, a readiness check that fails on downstream dependency errors removes healthy instances from rotation and can convert a partial degradation into a full outage. Separate liveness (process responsive) from readiness (dependencies satisfiable), and cache or rate-limit expensive checks.

Failure modes

• Silent non-integration — the bundle installs into Laravel but never boots; the route 404s while the team believes health checking is live. This is the most likely and most dangerous outcome, because it fails open.
• False negative — probe reports unhealthy due to a flaky dependency check; LB/k8s evicts good capacity and amplifies a minor blip.
• False positive — health check passes while the application is functionally degraded; alerting never fires.
• Information disclosure — unauthenticated endpoint exposes DB DSNs, versions, or env metadata.
• Upgrade breakage — an unmaintained constraint blocks a PHP or Laravel upgrade, forcing an emergency rewrite on someone else's timeline.

Ramp-up — low effort, misdirected. The package is simple enough that any engineer can learn it in an afternoon. The problem is that the ramp is spent on a dead dependency and a framework the team may not run, rather than on the organization's monitoring contract and probe policy. That engineering time is better spent on the contract definition and a maintained Laravel implementation.

TPM recommendation. Do not adopt for the Laravel/PHP estate. Escalate the decision as: (1) confirm whether any Symfony service exists that justifies a look; (2) standardize a health-check contract and adopt a maintained Laravel-native implementation; (3) if the bundle is used anywhere, fork, pin, and assign explicit ownership with a review date. The 32.48 opportunity score reflects a genuinely valuable category paired with a package that is not a viable dependency — the right move is to capture the category value with different tooling.