Zenddiagnostics Laravel Package

Product Decisions This Supports

• Feature scoping: the "health endpoint" decision. This package supplies the check primitives (disk space, writable paths, DB connectivity, cache/APCu, PHP version and extensions, stream wrappers, security advisories via SensioLabs) plus a Runner and result objects. The product decision it informs is whether a /health or /status endpoint ships in v1 — for anything with an uptime SLA, on-call rotation, or k8s/load-balancer probes, the answer is usually yes, and this is a shopping list of what to check rather than a reason to build checks from scratch.
• Roadmap: deployment and release gating. Health checks are the cheapest way to turn "did the deploy work?" into an automated yes/no. Decide whether post-deploy smoke checks and readiness probes are in the current milestone or deferred — this package is a low-effort way to prototype that path before committing engineering time.
• Build vs. buy vs. borrow. The real decision is tri-modal: (a) adopt this package, (b) adopt its maintained successor (laminas-diagnostics), or (c) borrow the check taxonomy and write ~200 lines of Laravel-native checks. Given the archived status, the pragmatic recommendation is (b) or (c) — but this package's check list is a legitimate input to the scope of (c), which is where the PM value sits.
• Use cases worth naming explicitly: liveness/readiness endpoints for orchestration, post-deploy smoke tests in CI/CD, customer-facing status pages, on-call dashboards, and pre-launch environment verification (storage permissions, queue connectivity, mail transport).
• Incident response posture. A standardized check suite shortens time-to-diagnosis during incidents and reduces "is it us or the DB?" back-and-forth. That's a measurable MTTR lever, which is the argument that gets it prioritized over feature work.

When to Consider This Package

Consider it when:

• You are already on a Zend Framework / Laminas-adjacent stack and its result/reporter interfaces slot into existing tooling.
• You need a check taxonomy to copy, not a runtime dependency — treat it as reference material for an in-house health module.
• The integration is short-lived or internal (a stopgap endpoint, a one-off pre-launch audit) where a vendored, permissively licensed (BSD-3-Clause) dependency is acceptable.
• You are willing to fork and vendor it. BSD-3-Clause permits this, which is the main mitigant to abandonment — but budget the maintenance cost honestly.

Look elsewhere when:

• Lifecycle matters. Last release 2019-11-22, archived, no security patching. For a product with a multi-year horizon this is a supply-chain liability, not a convenience.
• You need PHP 8.x support. The final release predates PHP 8; verify compatibility before it enters a composer.json, and assume you own any fixes.
• You are Laravel-native. This is framework-agnostic PHP with zero Laravel integration — no service provider, no config publishing, no artisan command, no Blade/JSON response helpers. You will hand-wire a controller or command and a reporter. Maintained Laravel-specific options (e.g. spatie/laravel-health, beyondcode/laravel-self-diagnosis, ohdearphp/laravel-health-check) or the maintained laminas-diagnostics successor deliver more value per hour of integration.
• You need reporters/alerting integrations, scheduling, or history. This gives you checks and a runner; the operational layer around it is yours to build.

How to Pitch It (Stakeholders)

To executives: "A health-check endpoint is a small, cheap piece of infrastructure that tells us — and our monitoring — whether the app and its dependencies are actually working, in production and immediately after every deploy. It's the difference between customers reporting an outage and our alerts doing it. The specific library we evaluated is archived, so my recommendation is to not take a dependency on it; instead we replicate its well-established check list in roughly two to three engineering days using maintained tooling. Same outcome, no abandoned code in our stack."

To engineering: "zendframework/zenddiagnostics is the classic PHP diagnostic-test suite — a solid catalogue of checks (disk, permissions, DB, cache, PHP version/extensions, security advisories) with a runner and result objects. It's archived, last shipped in 2019, has no PHP 8 guarantee, and is not Laravel-aware, so we'd own any fixes and write all the wiring ourselves. Proposal: use it as the specification, not the dependency — either adopt the maintained laminas-diagnostics successor or implement a thin in-house health module exposing a /health endpoint with a small set of checks behind it. Either way, the deliverable is the same: one endpoint, structured JSON, wired into our uptime monitor and post-deploy pipeline."