Health Check Bundle Laravel Package

Product Decisions This Supports

• Health/uptime visibility for the platform (build vs. buy). A health-check bundle answers a narrow but recurring question — "is this app healthy enough to receive traffic?" — behind a single endpoint your load balancer, Kubernetes probes, or external uptime monitor can poll. This supports a buy/adopt-small decision over writing and maintaining an in-house controller, service, and check registry.
• Framework currency on the roadmap. v0.3.0 adds Symfony 7 compatibility. That is a maintenance signal, not a feature: it tells you the package is tracking a currently supported framework major. It supports a "stay on supported framework versions" roadmap item by removing this package as a blocker to a Symfony 7 upgrade.
• Deployment and release-safety investment. Health endpoints underpin pre-deploy smoke tests, blue/green and canary cutovers, and rollback triggers. Adopting one standardizes how "ready" is defined across environments instead of each team inventing its own /status route.
• Scope correction that affects a real decision: this is a Symfony bundle, not a Laravel package. If the product roadmap is Laravel-first, this package is not adoptable as-is and the decision becomes "pick a Laravel-native health package or write a thin endpoint" — a genuine build-vs-buy call, not a drop-in. If the estate is mixed PHP, this may only cover the Symfony services.
• Concrete use cases to scope against: container liveness/readiness probes, load-balancer target health, external synthetic monitoring (Pingdom/BetterStack/UptimeRobot), status-page signal, and on-call triage ("is it the app or the database?").

When to Consider This Package

Consider it when:

• You run Symfony 6.4 or 7.x on a supported PHP version and want dependency-injection-friendly, composable health checks rather than a hand-rolled controller.
• You need an HTTP status + aggregated JSON style endpoint consumable by probes and monitors, and you want that behavior consistent across services.
• You value a small dependency footprint over a full observability platform integration.
• You are willing to accept pre-1.0 versioning (0.x) and pin exact versions in composer.json.

Look elsewhere when:

• Your application is Laravel — the bundle's service provider and Symfony HTTP kernel assumptions do not apply; evaluate a Laravel-native option or a ~50-line internal endpoint instead.
• You need real observability: metrics, tracing, dashboards, alert routing. Pair a health endpoint with OpenTelemetry/Sentry/Prometheus and an external monitor; do not expect this to replace them.
• You need support guarantees, SLAs, or a security-response commitment — a small-vendor 0.x package is unlikely to provide them.
• Your platform (PaaS, managed runtime) already exposes a health endpoint, making this redundant surface area.
• You need checks the package does not ship (queue depth, third-party API reachability, business-level invariants) and would end up writing most of the logic yourself anyway.

Risk notes for the review: v0.3.0 is additive only — one feature commit, no breaking changes, no deprecations, so upgrade risk from 0.2.1 is low. But the release is a single compatibility commit, which is evidence of maintenance, not of active development; treat maintenance cadence and bus factor as open diligence items before depending on it in production.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost operational safety net — a standard way for our services to report whether they are healthy, so deployments, load balancers, and monitoring can make automatic decisions. The latest release (v0.3.0) is a compatibility update that keeps it working on current Symfony versions; there are no breaking changes and no migration work. Cost is negligible; the benefit is faster detection and cleaner rollbacks. Main caveat: it is a young, small-vendor package, so we should pin the version and not make it load-bearing for anything beyond health signaling.

For engineering: One dependency, standard probes, no bespoke controller to maintain. v0.3.0 only adds Symfony 7 support — safe bump from 0.2.1, pin exact versions given 0.x semantics. It complements, not replaces, our metrics/tracing/alerting stack. Before adopting, confirm PHP version support, review the check interface for extensibility, and confirm it is Symfony-only — for Laravel services we need a separate answer.