Symfony Health Check Bundle Laravel Package

Technical Evaluation

Architecture fit

• Framework mismatch is the headline finding. macpaw/symfony-health-check-bundle is a Symfony bundle (type: symfony-bundle), not a Laravel package. It hooks into Symfony's kernel: registration in config/bundles.php, a DependencyInjection\Extension config tree, a compiler pass for tagged checkers, and a kernel event subscriber that binds the route. Laravel runs none of that machinery. There is no extra.laravel.providers entry and no service provider to discover.
• What is portable: the individual checker classes (if they have no container assumptions) and, more importantly, the JSON response contract and 200/503 status semantics. What is not: routing, configuration, checker discovery/tagging, and the aggregate orchestration — i.e. most of what the bundle actually does.
• Where it genuinely fits: any Symfony service in the estate. There it is a one-line registration plus checker tags, and it is a reasonable standard.
• Reusable value in a Laravel context is design-level, not runtime-level: adopt the response schema and status vocabulary; do not adopt the wiring.

Integration feasibility

• Symfony: trivial. composer require, enable the bundle, tag checkers, import the route. Under an hour.
• Laravel: not feasible natively. A bridge means writing a service provider that manually instantiates each checker, plus a controller that invokes the aggregate — at which point the bundle's core value (discovery and wiring) has been reimplemented in-house, and only the checker bodies survive. Estimate 1–2 days for a spike, with permanent unsupported-path maintenance afterward.
• Dependency creep: some checks likely bind to Symfony Contracts or components (cache, lock, HTTP client, process). Laravel does not supply those; pulling symfony/cache alongside illuminate/cache creates two parallel infrastructure configurations and two sources of truth for connection settings — an operational smell for a health endpoint.
• The Composer trap: the package will install cleanly into a Laravel app and then do nothing. Installability is not integration.

Technical risk

• High in a Laravel stack, low in Symfony. The risk is architectural, not code quality.
• Governance: 62 stars, 0 dependents, single-vendor stewardship (MacPaw). Recent release (2026-05-06) shows activity, but there is no downstream validation, no third-party tooling, and no community backpressure. Bus factor is the dominant concern.
• Blast radius: health endpoints sit on the critical path for orchestrators and load balancers. A wrong check causes restart loops or capacity drain — a production availability incident, not a cosmetic bug.
• Exposure risk: health payloads leak topology (DB reachability, queue lag, version strings) if reachable publicly.
• License: MIT — no legal friction; safe to read, fork, or vendor.

Key questions

1. Does any part of the estate actually run Symfony? If no, this evaluation closes as "not adopted."
2. Is the deliverable the library or the health contract? If the latter, the library is optional on both sides.
3. What do we already have — Laravel 11's built-in /up route, spatie/laravel-health, cloud LB probes, APM agents?
4. Who owns upgrades if the vendor goes quiet?
5. Do any checks touch write paths, deep DB queries, or queue introspection that would be unsafe at probe frequency?
6. Is the endpoint mesh/ingress-restricted or public?

Integration Approach

Stack fit

• Laravel-first: does not fit. Do not add it. Two sane paths: (a) implement the pattern natively — a /health (liveness) and /health/ready (readiness) controller returning aggregate JSON with 200/503 — via spatie/laravel-health or a thin in-house package; (b) if specific MacPaw checks are genuinely wanted, consume those classes as leaf utilities behind a Laravel service provider, with zero reliance on its routing or configuration.
• Mixed Symfony + Laravel estate: use the bundle properly on the Symfony side, and mirror its response schema in Laravel so the platform team has one dashboard and one alerting contract. The schema becomes the standard; the library becomes one conforming implementation.

Migration path

• Define the contract first: {status, checks:[{name, status, duration_ms, detail}], version, timestamp} with a fixed status vocabulary. Map both frameworks onto it.
• If already embedded in a Symfony app: no migration — verify its Symfony major constraint against the kernel version in use.
• If someone has already bridged it into Laravel: plan to unwind. Replace with native checks, preserve the JSON shape, delete the Symfony DI surface. Keep the contract tests.

Compatibility

• PHP version constraints are not the blocker — Laravel 11/12 and this bundle both sit in modern PHP territory. The blocker is framework semantics.
• Watch for partial symfony/* overlap already present via Laravel's transitive dependencies; adding more can produce confusing container/config error surfaces that cost debugging time out of proportion to the value delivered.
• Composer resolution will likely succeed in a Laravel app — this is precisely the silent no-op risk and the reason to reject the bridge rather than pilot it.

Sequencing

1. Inventory frameworks — confirm whether any Symfony services exist.
2. Freeze the health response contract and status vocabulary (this is the durable artifact).
3. Ship native /health and /health/ready in Laravel services with network scoping.
4. Only then evaluate this bundle for the Symfony slice as a conformance implementation.
5. Add schema + status-code contract tests in CI so both sides stay in lockstep.

Operational Impact

Maintenance

• Symfony: low — routine composer update, follow majors.
• Bridged Laravel: high hidden cost. Every upstream release is a manual re-validation against a wiring path the maintainer neither tests nor supports. That cost is recurring and invisible until it breaks.
• Ecosystem thinness: 62 stars and zero dependents means no tutorials, no forks to lean on, no community patches. Budget for the possibility of vendoring or forking outright.

Support

• Support channel is the upstream repo's issues; no SLA. Acceptable for an internal liveness signal, unacceptable if the endpoint is a customer-facing uptime claim.
• Assign explicit internal ownership (platform/SRE). Health endpoints added ad hoc by whichever team added the Composer line are how you get three different status vocabularies.

Scaling

• Probe cost multiplies by probe frequency × instance count. A dependency-touching check at 1s intervals across hundreds of pods becomes real load on the very dependencies it monitors.
• Mitigations: separate cheap process-local liveness from dependency-touching readiness; cache check results for a few seconds; keep the endpoint off public ingress; cap total check timeout so a hung dependency cannot stall the handler.

Failure modes

• False negative → orchestrator restarts healthy pods or the LB drains capacity → self-inflicted outage. Usually caused by a readiness check stricter than the actual serving path.
• False positive → traffic routed to an instance that cannot serve. Quieter, more damaging.
• Silent no-op in Laravel after a Composer-only install: no route registered, team believes health checking is live, monitoring never fires. This is the signature risk of the framework mismatch and the deciding argument against the bridge.
• Information disclosure if the endpoint is publicly reachable.
• Upgrade lock-in: if the vendor stalls, the Symfony app is pinned to an aging major, which blocks framework upgrades estate-wide.

Ramp-up

• Symfony engineer: ~1 hour — install, enable, tag checkers, import route.
• Laravel engineer: days of Symfony kernel/DI work for throwaway knowledge, and the resulting bridge is unsupported.
• Documentation is README-level; expect to read the extension class directly for config keys and the tag name.

TPM recommendation: do not adopt for the Laravel stack — the package installs but cannot function there, and a bridge reimplements its only real value while inheriting an unsupported maintenance path. Treat it as a reference implementation for the health response contract, and as a genuine adoption candidate only for the Symfony slice of the estate, if one exists.