Server Status Laravel Package

Technical Evaluation

What it is: innmind/server-status is a framework-agnostic PHP library for composing service health/status checks (databases, caches, HTTP dependencies, sockets) into a single aggregated status result. It is not a Laravel package — there is no ServiceProvider, no publishable config, no Facade, no Artisan commands.

Architecture fit

• Fits cleanly as a domain library inside a Laravel app: bind the status aggregator as a container singleton and call it from a controller or scheduled command.
• Uses Innmind's functional style (immutable collections, monadic error handling, innmind/* primitives). This is idiomatic in that ecosystem but foreign to typical Laravel codebases, so it must sit behind a thin, app-owned adapter interface.
• No opinion on transport or output format — you own JSON shaping, HTTP codes, and log emission. That is good for flexibility, bad for out-of-the-box velocity.

Integration feasibility

• Installable via Composer; footprint is small. Feasibility is moderate: the work is not the library, it's the adapter, the scheduler wiring, and the caching layer around it.
• Risk of dependency friction with illuminate/* / symfony/* is real given Innmind's independent release cadence — verify with composer why-not against the target Laravel version before any design work.

Technical risk

• High bus-factor risk: 1 maintainer, 7 stars, 0 dependents. Effectively unvalidated in production by anyone but the author.
• API drift: Innmind libraries iterate aggressively; concrete classes are more likely to churn than interfaces. Depend only on the narrowest surface, wrapped.
• No security/ disclosure policy, no CI badge evidence from the repo surface, no LTS branch expectation.
• Maturity mismatch with the score (16/100) and a low opportunity signal (35.26): this is a tactical utility, not a platform bet.

Key questions to resolve before committing

1. Does it perform active probes (opens sockets, executes processes) or merely aggregate externally supplied results? Active probing raises timeout, privilege, and egress-firewall concerns.
2. Is the dependency surface small enough to vendor/fork if abandoned?
3. What is the PHP floor, and does it conflict with our supported runtime?
4. Does it expose stable interfaces we can implement against, or only final concrete classes?
5. Does it require shell execution (exec, proc_open) — a non-starter on hardened/read-only containers?
6. Are check timeouts and per-check failure isolation built in, or must we impose them?

Integration Approach

Stack fit

• Treat as a library, not a bundle: < Laravel 11 app + Composer + PHP 8.x. Wire it through a single app-owned HealthCheckService that implements our interface and delegates to the package. Nothing else in the codebase should import Innmind\ServerStatus\*.
• Two consumption points: (a) a /health and /health/deep controller returning a stable JSON contract; (b) a scheduled command writing results to cache for cheap reads.

Migration path

1. Spike (1–2 days): install in a scratch branch, exercise the API, confirm probe semantics and timeout behavior.
2. Shadow mode: run the package alongside existing health checks for 2–4 weeks, logging both outputs; diff results to calibrate thresholds and eliminate false positives.
3. Feature flag: expose the new endpoint behind a flag per environment; internal consumers (LB, uptime monitors, k8s probes) migrate last.
4. Cutover and decommission the legacy checks only after a full on-call cycle with no unexplained deltas.

Compatibility

• Pin exact versions (composer require innmind/server-status:x.y.z) and commit the lock file; forbid ^ ranges for this dependency.
• Validate against each Laravel minor upgrade in CI, since Innmind's release cadence is decoupled from Illuminate's.

Sequencing

1. Dependency audit and version pinning.
2. Adapter interface + implementation (the only place the package appears).
3. Cached status repository (Redis/array store) with TTL.
4. Controller + scheduled command + Artisan wiring.
5. Observability: structured logs, metrics for check latency and status transitions.
6. Runbook and ADR documenting the "vendor-in-place" fallback plan.

Operational Impact

Maintenance

• Budget for ownership, not usage: expect to fork or vendor the package within 12–24 months given the bus factor. Keep the adapter thin so a swap is a one-file change.
• Track upstream releases manually; there is no dependabot signal to rely on beyond your own pinning discipline.

Support

• No SLA, no commercial backing, effectively no community. Internal escalation path is "we fix it." Get that accepted explicitly before adoption.

Scaling

• Health checks are I/O-bound and fan out: N instances × M dependencies. Never execute deep checks per request at high QPS — serve cached results (15–30s TTL) and run the real probe on a single elected worker or scheduler to avoid thundering-herd probing that can itself take down a degraded dependency.
• Enforce per-check timeouts and a global budget; a status endpoint that hangs is worse than one that reports "unknown."

Failure modes to instrument

• Health endpoint returning 5xx on an uncaught library exception — wrap all calls, degrade to degraded, never throw to the client.
• Cascading false negatives when a shared dependency (DB, Redis) is slow rather than down.
• FD/memory growth in long-running workers if the library leaves handles open per check.
• Probe traffic amplifying an ongoing incident — cap concurrency and add jitter.
• Silent staleness: a cached status that stops updating must expire to unknown, not stay healthy.

Ramp-up

• Low-to-moderate. A mid-level Laravel developer needs ~1–2 days to become productive, most of it spent on Innmind's functional idioms (immutable structures, wrapped error types) rather than on health checking itself.
• Mitigate with the adapter boundary, a short internal README, and one worked example per check type. Do not let the functional style leak into controllers or domain code.

Recommendation: Adopt only as an internal, non-critical health-aggregation utility, behind an app-owned interface, pinned and shadow-tested. Reject for anything on the critical path (payment, auth, deploy gating) until it has either meaningful dependent count or an actively maintained fork.