Nova Server Monitor Laravel Package

Product Decisions This Supports

• Where ops telemetry should live — this package answers exactly one product question: do we surface server health inside the admin panel our team already has open? It is only meaningful if the answer is "yes, inside Laravel Nova." It says nothing about what to measure, how often, or at what thresholds — that logic belongs entirely to spatie/laravel-server-monitor. Use it to frame the discussion, not to settle the requirements.
• Build vs. buy vs. assemble — commercially MIT and free, but functionally it's "assemble": two third-party dependencies plus a ~30-line presentation layer. The durable value is in the Spatie library; the wrapper is glue. Useful precedent the next time engineering pitches a thin integration as a differentiator.
• Roadmap signal, not roadmap content — 65 stars, 0 dependents, last release 2018-12-08, single maintainer, and the upstream Spatie package has itself been superseded by spatie/laravel-health. That's the market saying the "monitoring inside the admin panel" niche is small and that most teams deliberately keep observability out of Nova. Strong evidence for the next in-app-dashboard pitch.
• Use cases it validates as a concept — on-call triage from a phone (glance at disk/CPU/memory before opening a terminal), agency/multi-tenant ops (each client's Nova shows its own box), and incident review where a health snapshot sits next to application data. Good inputs for a requirements doc; not a reason to adopt this code.
• A cheap "do nothing" validation — for a team already on Nova 1.x/2.x and already running Server Monitor, adoption is zero-cost confirmation that an in-admin health card saves a few context switches. If that team doesn't exist inside your org, the decision has made itself.
• Explicitly out of scope, and worth saying out loud before anyone budgets — capacity planning, trend analysis, SLO tracking, fleet-wide views, retention, and alert routing. The card is a read-only view of the most recent check results: no storage of its own, no graphs, no paging.

When to Consider This Package

Treat it as a reference implementation, not a dependency. Consider it only when all of the following hold:

• You run Laravel Nova 1.x/2.x on PHP 7.x with no near-term upgrade planned — realistically the only environment where the code runs unmodified.
• You already own a Nova license and already collect metrics with spatie/laravel-server-monitor. If either is missing there is no partial-value story; the card renders nothing useful.
• Your needs fit the built-in check set (disk, load average, memory, reachability) with no custom checks, no history, and no alerting beyond what the Spatie library already provides.
• You can accept a small, permanently owned artifact — a fork or a 200–400 LOC reimplementation — and can name an owner for it.
• You accept the ongoing tax: roughly 1–3 engineer-days per Nova major upgrade, indefinitely, against a package with no tests, no CI, no security response channel, and no upstream fix coming.

Look elsewhere when:

• You're on a modern stack (Laravel 10–12, PHP 8.2+, Nova 4/5, Vue 3 + Vite). Nova 4 changed tool registration and moved the asset pipeline to Vite; this will not install. Budget a rewrite, not an install — any estimate starting with "just composer require" is unvalidated.
• You don't own Nova. The ~$199/site license plus renewals dwarfs the value of a status card; this wrapper cannot carry that commercial decision on its own.
• You need trends, fleet views, retention, or alert routing. Those belong to spatie/laravel-health or a dedicated service (Oh Dear, Uptime Kuma, PagerDuty, CloudWatch).
• A successor path exists. spatie/laravel-health supersedes laravel-server-monitor. If in-admin health is genuinely wanted, evaluate a thin Nova card or Filament widget on top of that rather than reviving this.
• You can't tolerate abandonment risk. No commits or releases in ~7 years, 0 dependents, single maintainer.

How to Pitch It (Stakeholders)

Executives: "It's a free MIT plugin that puts server health — disk, CPU, memory, uptime — onto a page engineers already have open, instead of standing up another login. Marginal cost is near zero if we already own Nova. The catch: it's been unchanged since 2018, has zero downstream users, and won't run on our current stack — so realistically this is a one-to-two-week rebuild of the idea, not an install. It's a backlog candidate for internal tooling, not a purchase, and not a differentiator: the market signal is that most teams keep monitoring out of the admin panel on purpose. Recommendation: don't adopt; harvest the idea only if in-admin health is a funded requirement for a specific Nova-based team."

Engineering: "Thin Nova tool over spatie/laravel-server-monitor — read-only display of whatever the last check wrote. Three layers to debug: artisan command output, then monitor_events rows, then the card's JSON endpoint. The most common failure is a missing scheduler entry producing a permanently green dashboard that is silently stale, so verify freshness before touching the frontend. Do not install on Nova 4/5 or PHP 8.x — the Vue 2/Webpack chain and the old registration pattern don't survive. If we build it, the shape is one read-only Nova endpoint plus a metric-tile component against spatie/laravel-health, roughly 200–400 LOC, and we own it — name an owner or it orphans at the first team change."

Scope guardrail for both audiences: label the card explicitly as a status view, not an incident channel. Alerting lives in the Spatie config and goes wherever that sends it. Without that label, someone will eventually ask why nobody was paged.