Monitor Laravel Package

Technical Evaluation

Bottom line: Do not add liip/monitor as a runtime dependency. Treat it as a design reference for a health-check registry inside a Laravel app.

Architecture fit

• LiipMonitor's model is a CheckInterface (single check() returning a Result with status + message) plus a Runner that registers checks into named groups and aggregates results. That shape is framework-agnostic and maps 1:1 onto a Laravel container binding + an App\Support\Health\HealthCheck contract.
• There is no Laravel integration surface: no service provider, no config publish, no facade, no artisan command, no route, no JSON endpoint. Every binding (controller, route, scheduler entry, output format, alerting) is ours to build.
• Laravel 11 already ships a built-in health route (health: '/up' in bootstrap/app.php), and the ecosystem-standard replacement is spatie/laravel-health (actively maintained, ships DB/Redis/cache/Horizon/queue/disk/HTTP checks, JSON endpoint, result history). Functional overlap with LiipMonitor is roughly 90%.

Integration feasibility

• Conceptually trivial — the API surface is ~3 classes. Practically blocked: last release 2014, archived, 0 dependents, predates PSR-4/PSR-12 norms, almost certainly not PHP 8.2/8.3 clean (missing return types, dynamic properties, PHP 5.4-era idioms), and its optional checks reference dependency versions from the Symfony 2 era.
• A Composer install will likely fail platform constraints or require --ignore-platform-reqs, importing a legacy transitive tree for functionality we can re-implement in about a day.

Technical risk (ranked)

1. Unmaintained code in the runtime path — no security patches, no PHP 8 fixes. A latent fatal inside a check takes down the health endpoint, which is precisely the endpoint you depend on during an outage.
2. Abandonment signal — no maintainer, no triage, no upgrade path. Adoption creates a forced future migration with no upstream to lean on.
3. False confidence — a green /health that only asserts "PHP is running" is worse than none; it suppresses the alerting you actually need.
4. Blast radius of checks — synchronous DB/Redis/queue checks under orchestrator polling can amplify an incident.
5. Low: license (MIT, clean); code volume small enough to audit in an afternoon.

Key questions

• What is the requirement: container liveness/readiness, an internal status page, or an external paging signal? Each implies different check depth and SLA.
• Which dependencies must be asserted (MySQL, Redis, Horizon workers, S3, third-party APIs), and what is the latency budget per check?
• Does an existing uptime monitor already cover surface availability, making deep checks redundant?
• Who owns the runbook when a check flips to CRITICAL, and does on-call know what each check means?
• Are we willing to own a forked check-runner indefinitely, or should this be a thin in-house module with no upstream pretence?

Integration Approach

Stack fit

• Target: Laravel 10/11/12, PHP 8.2+. Native fit is a HealthCheck interface, tagged bindings in a service provider, a HealthController, and Cache-backed result storage. Route sits outside web/auth middleware, optionally behind a signed URL or IP allowlist.
• LiipMonitor contributes the vocabulary — Check / Result / Status / Group / Runner — not code. Reuse the naming so engineers reading its docs (or the LiipMonitorBundle check catalogue) map concepts instantly.

Migration path

• There is nothing to migrate at runtime: 0 dependents, no Laravel installs, no transitive consumers. This is greenfield adoption of a pattern, so the "migration" is really a build decision.
• Recommended: a 0.5–1 day spike reading the repo's Check/Runner/Result classes and the bundle's check catalogue to harvest a requirements list, then implement in-house or adopt spatie/laravel-health if the catalogue matches.
• If a legacy Symfony app in the org runs liip/monitor-bundle, keep the contract compatible (same OK/WARNING/CRITICAL/UNKNOWN status vocabulary) so one dashboard can consume both.

Compatibility

• Composer: expect php: >=5.3.3-style constraints and abandoned optional deps. Do not attempt to satisfy them; if a spike requires execution, isolate in a throwaway container, never in the app's composer.json.
• Output contract: JSON {status, checks: [{name, status, message, duration_ms}]}, HTTP 200 for OK and 503 for CRITICAL — matches k8s probe semantics and reverse-proxy health checks.

Sequencing (estimates, 1 engineer)

1. Day 1 — decision spike. Read archived source, extract the check catalogue, compare to spatie/laravel-health and native /up. Deliverable: build-vs-adopt one-pager.
2. Day 2–3 — core. HealthCheck contract, tagged registration, runner with result aggregation, /health JSON route; leave /up as the cheap liveness probe.
3. Day 4 — checks. DB (DB::select('select 1') with timeout), cache put/get, Redis PING, Queue::size(), Horizon status, storage free space, one external HTTP check with a 2s timeout.
4. Day 5 — separation of concerns. Split liveness (no dependencies) from readiness (dependency checks); cache readiness 30–60s; move slow checks to a scheduled job writing into cache.
5. Week 2 — alerting. Route CRITICAL transitions to the existing alert channel, add a check-latency panel, write the runbook.

Operational Impact

Maintenance

• Adopting the package: unbounded and unowned — archived upstream means all fixes are ours with no rebase target. Reject.
• In-house/spatie route: ~50–150 LOC to own, low churn, reviewed like any app code. Cost is a few hours per quarter plus adding a check whenever a new dependency lands.

Support

• No vendor, no maintainer, no triage. Any question ("why UNKNOWN?") is answered by reading 2013-era source.
• Internal cost concentrates on interpretation: every CRITICAL must map to an action. Budget for the runbook and on-call training, not for library support.

Scaling

• Health endpoints scale badly by default: orchestrators poll every 5–10s per instance. Mitigations — liveness must be dependency-free and sub-10ms; readiness cached 30–60s; heavy checks (HTTP, disk, queue depth) moved to the scheduler and read from cache; exclude /health from tracing sampling and access-log noise.
• At 20 pods × 6 polls/min, deep synchronous checks add ~120 DB round-trips/min of pure overhead — measurable during an incident. Caching is not optional.

Failure modes

Ramp-up

• Concept ramp-up is under a day for any mid-level Laravel engineer; Check/Result/Runner is a whiteboard-sized model.
• The real cost is domain knowledge: which checks matter, what latency is normal, who acts on a CRITICAL. That lives in the runbook, not the package.
• Do not let the archived provenance leak into onboarding. Frame it as "we built a health-check module modelled on a well-known pattern" so new engineers don't inherit maintenance anxiety about a dead dependency that isn't actually installed.

TPM recommendation: Reject as a dependency (0/10 risk-adjusted adoption value); reference it for API design (7/10 concept value — which is what the 7.55 opportunity score actually flags: a well-shaped idea with no living implementation). Ship a thin in-house module or spatie/laravel-health, whichever the day-1 spike favors, and reinvest the saved effort into the runbook and alert routing.