Health Bundle Laravel Package

Product Decisions This Supports

• Roadmap: health/readiness standardization. If there's a platform initiative to give every service a uniform /health contract (probe path, status codes, payload shape), this package is one candidate implementation to evaluate against building it in-house.
• Build vs. buy — and here the answer leans "build." A /health endpoint is roughly 30–50 lines of routing and a few dependency pings. The buy-vs-build conversation this package actually forces isn't "can we afford it" but "what do we want behind the endpoint" — liveness vs. readiness, which dependencies to check, whether a degraded dependency should return 503 or 200-with-warnings, and who owns that logic when it pages someone at 3 a.m.
• Deploy gating and rollback. A health endpoint is the promotion signal for canary/blue-green rollouts, Kubernetes liveness/readiness probes, and load balancer target-group checks. Standardizing it is a prerequisite for safe progressive delivery.
• Incident response and on-call. It's the first thing an uptime monitor and an on-call engineer hit. Consistency here shortens triage.
• Compliance evidence. Availability controls (SOC 2, ISO 27001) increasingly ask for demonstrable liveness monitoring; a uniform endpoint makes that auditable rather than bespoke.

When to Consider This Package

Adopt only if all of these hold:

• You are on Symfony. This is a Symfony bundle; it cannot be installed into a Laravel application. If the stack under discussion is Laravel, this package is out of scope — Laravel 11+ ships a built-in /up health route, and spatie/laravel-health covers deeper dependency checks. Confirm which framework the target service actually runs before this enters a backlog.
• You want a minimal, zero-configuration endpoint and nothing more.
• You're willing to read and audit the source, pin an exact version, and accept ownership of a fork if it's abandoned.

Look elsewhere (or build in-house) when:

• Vendor-risk tolerance is low. 0 stars, 0 dependents, a single maintainer, and no downstream usage means no ecosystem validation, no de facto security review, and no signal that breakage will be noticed by anyone but you. That matters disproportionately for a component sitting on the critical path of every deploy — a broken health endpoint can fail a rollout or, worse, mask a real outage by returning 200.
• You need more than a boolean. Per-check reporting, JSON output for dashboards, check caching/timeouts, and alerting integrations are the reasons people adopt a health package; a bare endpoint doesn't clear that bar.
• You already have a convention. If platform engineering has a shared middleware or base controller pattern, adding a bundle creates a second standard to maintain.
• Maturity signals are unclear. The listed last release (2026-08-21) should be verified against real, reproducible tags and a changelog before anything is pinned.

How to Pitch It (Stakeholders)

For executives: This is a tiny, MIT-licensed Symfony bundle that adds a /health endpoint — the URL load balancers and monitoring tools use to check whether a service is alive. Cost is near zero and there are no licensing concerns. The caveat is maturity: zero stars, zero downstream users, one maintainer. My recommendation is to treat it as an input to our health-check standard rather than a production dependency. Building the equivalent ourselves is under a day of engineering and gives us full control over what "healthy" means — which is the part that actually matters during an incident. Decision requested: approve in-house implementation as the default, with this package as a reference, unless a team on Symfony needs a stopgap this sprint.

For engineering: Thin wrapper around a route plus dependency checks. It's a Symfony bundle — not usable in our Laravel services. Before any adoption: read the source end to end, confirm the release tags are real and reproducible, pin the version, and document a fork-or-replace path. Do not put an unvetted third-party health endpoint behind a production load balancer without deciding what it returns when a downstream dependency is degraded rather than down.