Actuator Bundle Laravel Package

Product Decisions This Supports

• Observability and reliability roadmap: whether health probe endpoints become a standardized contract between our application and the infrastructure that runs it (orchestrator, load balancer, uptime monitor).
• Build vs. buy vs. borrow: do we hand-roll a /health controller, adopt a bundle that already encodes Spring Actuator conventions, or copy the pattern into our own code? This package is small enough that "borrow the idea" is a legitimate third option.
• Deployment strategy: liveness vs. readiness separation is the gate for rolling deploys, blue/green cutovers, and canary analysis. Without a readiness probe, a rollout strategy is theoretical.
• SLA and incident response commitments: probes are the machine-readable input to alerting, status pages, and on-call escalation. Committing to an uptime target requires deciding what "healthy" means in code.
• Platform migration decisions: any move to containers or Kubernetes makes a probe contract mandatory. Choosing the probe shape now is cheaper than retrofitting it during the migration.
• Framework upgrade path: v1.1.0 adds Symfony 7.0 compatibility. If any of our Symfony services are pinned below 7 because of a probe dependency, that blocker is now gone — and conversely, adopting this bundle no longer constrains a future Symfony major upgrade to 6.x. This is a small but concrete input to "can we take the Symfony 7 upgrade this quarter?"
• Tooling consolidation: one consistent health endpoint shape across services versus per-service snowflakes that every on-call engineer has to learn separately.
• Prioritization input: whether health-check maturity is a blocker for an enterprise/compliance requirement or a platform migration, which would justify doing this work this quarter instead of next.

Concrete use cases: Kubernetes liveness/readiness probes, load balancer and ingress health checks, synthetic uptime monitoring, CI smoke tests post-deploy, canary promotion gates, and status page feeds.

When to Consider This Package

Important framework note: this is a Symfony bundle, not a Laravel package. In a Laravel codebase the decision is not really about this repository — the idiomatic equivalents are spatie/laravel-health or the framework's built-in health route, both of which are better maintained and better integrated.

Consider it when:

• The stack is Symfony and you want Spring Actuator-style semantics (aggregated health, liveness/readiness split) without designing the contract yourself.
• You are on, or plan to move to, Symfony 7 — v1.1.0 explicitly declares Symfony 7.0 compatibility, which removes the most likely hard blocker for a modern Symfony codebase.
• The scope is genuinely just probe endpoints — no metrics, no tracing, no dashboards.
• You are willing to vendor or fork it. MIT licensing makes that legally safe, and the surface area is small enough that forking is cheap.
• You need it as a convention reference or a spike, not as a load-bearing production dependency.

Look elsewhere when:

• You need Laravel integration. Out-of-the-box fit is poor and you'd be maintaining a compatibility shim.
• You need real observability. Metrics, tracing, and dashboards belong to OpenTelemetry, Prometheus exporters, or Sentry — not to a health bundle.
• You need maintenance guarantees. Signals remain weak despite the new release: 1 GitHub star, 0 dependents, a single maintainer, and a sparse history (one minor release since December 2023). v1.1.0 shows the project is not abandoned, which is a genuine improvement on the prior assessment — but a one-PR compatibility bump is a maintenance pulse, not a cadence, and zero dependents still means no ecosystem validation. That is a risk signal, not a quality judgment.
• You need enterprise support, security SLAs, or a predictable release cadence. None exist here, and one release does not create them.
• You need deep framework-aware dependency checks (database, queue, Redis, third-party APIs) with idiomatic configuration — better-served by maintained community options.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, MIT-licensed way to get standard health probe endpoints — the plumbing that lets us deploy safely and detect outages automatically — which we would otherwise build ourselves. The dependency-risk picture improved slightly with v1.1.0, which adds Symfony 7 support and shows the project is still maintained; it is no longer untested against current Symfony. The underlying risk is unchanged, though: a small, single-maintainer Symfony bundle with one star, no downstream dependents, and a sparse release history. Recommendation: fund a short, time-boxed spike, treat the output as a reference implementation or a vendored component, and do not put it on the critical path without an owned fork. For Laravel services, use the maintained community equivalent instead and skip this package entirely.

To engineering: It encodes Spring Actuator conventions — health and info-style probes with a liveness/readiness split — which is precisely the contract Kubernetes and load balancers expect, so adopting the convention saves design time. It is Symfony-only; on Laravel use spatie/laravel-health or the built-in health route. v1.1.0 is a single-change release adding Symfony 7.0 compatibility (PR #1), so it now installs cleanly on ^7.0 and won't block a Symfony major upgrade — check it against your other pinned constraints, since that compatibility claim covers framework wiring, not necessarily every transitive dependency. Because the code volume is small and the license is MIT, forking is cheap and safe. If we adopt it, pin the version, assign an owner, and treat the fork as ours — a fresh compatibility patch is welcome but does not change the expectation that upstream may not ship fixes.