Health Check Bundle Laravel Package

Product Decisions This Supports

• Health/readiness signaling for orchestration. Backs the decision of whether Kubernetes liveness/readiness probes, ECS health checks, or load-balancer target groups are served by an in-app health contract or by external APM (Datadog, New Relic, Sentry uptime). This bundle is the "in-app" option, for Symfony services only.
• Framework standardization. The critical qualifier: this is a Symfony bundle, not a Laravel package. If the roadmap is Laravel-first, this is out of scope and should be treated as a prompt to evaluate Laravel-native equivalents (Laravel 11's built-in /up route, spatie/laravel-health) rather than an adoption candidate.
• Build vs buy for a commodity capability. A /health controller with DB/Redis/disk checks is typically 1–3 dev-days. Buying only wins if the bundle gives you a check registry, per-check aggregation, a stable JSON schema, and correct HTTP status mapping (degraded dependency → 503) that you would otherwise re-implement per service.
• Dependency governance / vendor risk. Zero stars, zero dependents, single-maintainer origin (Silpo, a retail engineering team). Adopting means an explicit fork-or-vendor decision: pin the version, copy the source in-tree, or accept upstream risk.
• Ecosystem sensing. Published 2025-08-20 by a retail engineering org; a useful reference point that "standardized health contract" is being productized by platform teams, even if you build your own. Benchmark your internal implementation against it rather than adopting it wholesale.

When to Consider This Package

Consider it if:

• The service is on Symfony (check the bundle's version constraints against your 5.4/6.x/7.x footprint).
• You operate multiple Symfony services and want one consistent health JSON shape — status, per-check detail, timings — across all of them.
• You run containerized/orchestrated workloads and want readiness to fail on real dependency degradation, not return a static 200.
• You're comfortable with early-stage vendor code: budget time to read the source and write your own acceptance tests, since there is no community usage to lean on.

Look elsewhere if:

• You're on Laravel. There is no Laravel integration here; use Laravel's native /up endpoint or spatie/laravel-health.
• You need support SLAs, a security response process, or a release track record. Public adoption evidence is effectively zero.
• Your requirement is a single static endpoint for a load balancer — a short controller is lower total cost of ownership than a new dependency.
• You need deep probes (queue depth, Kafka lag, third-party API checks) the bundle doesn't ship; you'd write those anyway and the abstraction earns less.

How to Pitch It (Stakeholders)

Executive summary. HealthCheckBundle is an MIT-licensed Symfony bundle that adds standardized health and readiness endpoints to PHP services. It is a small, low-cost utility, not a platform bet. The strategic value is consistency: one health contract across services makes orchestration probes, autoscaling, and incident triage more dependable. It carries no licensing cost and no lock-in beyond the code itself.

Engineering summary. It replaces hand-rolled /health controllers with a check registry and structured responses, so dependency failures surface as proper non-200 statuses. Integration effort on Symfony is low. Two caveats to state plainly: it does not serve Laravel applications, and the project has zero public adoption with a single upstream origin — plan to vendor or fork the source rather than depend on it as-is.

Recommendation. Approve a timeboxed pilot (roughly one sprint) on a single non-critical Symfony service, and measure whether it actually displaces custom health code. Do not standardize org-wide until a second team adopts it or the source is vendored internally. For Laravel services, standardize on the framework's native health endpoint instead. Net position: cheap to try, cheap to abandon — fund it as a tactical pilot, not a roadmap initiative.