Health Check Bundle Laravel Package

Product Decisions This Supports

• Launch-gate readiness for any Laravel service going to production. A 1.0.0 stable release of a health-check bundle gives you a standardized /health (liveness/readiness) surface that load balancers, Kubernetes probes, and uptime monitors can consume — this is typically a release-checklist item rather than a feature, so it unblocks go-live decisions.
• Roadmap sequencing for observability work. Because the package covers shallow dependency checks (app boot, database, cache, queue, disk — verify the actual probe list) rather than full APM, adopting it lets you defer a larger observability investment and schedule tracing/metrics tooling later without blocking launch.
• Build vs. buy. The capability is small enough to hand-roll, but the decision hinges on maintenance cost and consistency across services. Adopting a maintained package avoids each team inventing its own probe payload and HTTP status conventions.
• Incident-response and SLO decisions. Uniform health signals make it possible to define availability SLIs and to make auto-restart / traffic-draining decisions mechanically instead of by convention.
• Multi-service standardization. If you run several Laravel services, a shared health-check contract simplifies platform templates, Helm charts, and on-call runbooks.
• Semver-stability signal. 1.0.0 is the first stable API; downstream platform standards can now pin ^1.0 without expecting churn. That matters for a platform-level mandate.

Caveat for the decision log: the 1.0.0 release notes contain no substantive changelog — no feature list, breaking-change list, or migration notes. Version number alone is the signal. Treat "stable API" as the claim to verify, and confirm probe coverage and endpoint/status-code behavior against the docs before committing it to a platform standard.

When to Consider This Package

Consider adopting when:

• You are deploying Laravel services to Kubernetes, ECS, or any environment with automated liveness/readiness probes.
• You have more than one Laravel service and want one health-check convention rather than per-team implementations.
• Your team is small and would rather not own health-check code, tests, and security review themselves.
• You want dependency-aware checks (DB, cache, queue, storage) exposed in a form your monitoring stack already understands.
• You need a stable, pinned dependency (^1.0) to put into a base image or service template.

Look elsewhere when:

• You need deep observability — tracing, RED/USE metrics, per-route latency. Health checks are a binary up/down signal, not a monitoring system; plan a complementary tool.
• Your platform already standardizes on a framework-agnostic health endpoint (e.g., a sidecar or shared Go service) — duplicating it adds surface area without benefit.
• Your compliance posture requires vendor/security review of every dependency and the package's maintenance and disclosure process can't be established.
• You need zero-dependency or very small footprint, and an internal ~50-line controller covers your probes.
• The docs don't clearly state probe behavior, failure status codes, and data exposure — an unauthenticated health endpoint that leaks dependency names or versions is a real security concern; confirm it is safe to expose or restrictable.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk infrastructure dependency that standardizes how our Laravel services report whether they're healthy. It gives us a stable 1.0 release to pin to, and it's the kind of thing that prevents avoidable launch delays and reduces mean-time-to-detect during incidents. Cost is minimal; the main risk is that release documentation is thin, so we'll validate behavior in staging before standardizing. Recommendation: adopt on one service as a pilot, then roll into the platform template if it holds up.

For engineering: Use this as the canonical health contract. Pin ^1.0 — first stable semver, so no expected API churn — and wire the endpoint to your orchestrator's readiness probe. Two asks before we standardize: (1) review the actual probe set and confirm failure semantics and HTTP status codes; (2) confirm whether the endpoint needs auth or network restriction before it's internet-reachable. Keep it strictly as an up/down signal — it is not a replacement for metrics or tracing, which stay on the roadmap as a separate item.