Nova Server Monitor Laravel Package

Technical Evaluation

Architecture fit. The package is a presentation-layer wrapper, not a monitoring system. It renders whatever spatie/laravel-server-monitor has already persisted — CPU load, memory, disk, uptime, load average — as a Nova dashboard card. Architecturally that is the right shape for the problem: a read-only view over data another component owns, with no schema of its own, no background process, no external service. The consequence is that all real behavior (which checks run, how often, at what thresholds, where alerts go) lives in the Spatie config, not here. The Nova card is roughly thirty lines of glue around that config. As a TPM this matters for scoping: adopting the card without the collector delivers a permanently blank dashboard, and tuning thresholds "in the card" is not a thing.

Integration feasibility. Feasible only in a narrow, legacy window: Laravel Nova 1.x/2.x, PHP 7.x, Vue 2/Webpack asset pipeline, and an already-running laravel-server-monitor install with the scheduler entry wired. Outside that window it is a source donor, not a dependency. Nova 4 changed tool registration (Nova::script() / Nova::style()) and moved the asset pipeline to Vite with Vue 3; Composer constraints will not resolve cleanly and the compiled bundle will not load. Estimate accordingly: a rewrite of 200–400 LOC, not a composer require. The cleanest integration path for a modern stack is a thin, self-owned card over spatie/laravel-health (Health::latestResults()), reusing this package's check-to-view mapping and discarding its service provider, routes, and frontend build.

Technical risk. High and mostly non-technical in origin:

• Abandonment. Last release 2018-12-08, ~7 years of no commits, single maintainer, 0 dependents, no tests, no CI, no security response channel. There is no upstream fix coming for anything, including a future CVE.
• Double legacy inheritance. The upstream Spatie library is itself superseded by spatie/laravel-health. Forking this card means owning two upgrade problems, not one.
• Silent staleness. The card never runs checks. A missing or broken server-monitor:run-checks schedule produces a serene, permanently green dashboard with no error worth debugging. Freshness is not surfaced in the 2018 UI — there is no visible "last checked at."
• Licensing dependency. Nova is ~$199/site plus renewals. A 65-star MIT wrapper cannot carry that commercial decision; it only rides a license already justified elsewhere.
• Unbounded data growth. monitor_events is not pruned by default; dashboard queries degrade on long-lived installs without a retention job.
• Second-wave breakage. After Composer clears, CSP and mix-manifest.json mismatches routinely block the compiled bundle — budget for it.

Key questions to settle before any work is scheduled:

1. Do we actually own Nova, on 1.x/2.x, and do we already run laravel-server-monitor? If either answer is no, the value proposition collapses — there is no partial-value story.
2. Who owns this artifact permanently, by name? If no one will, it orphans the first time the owning engineer changes teams.
3. Is the source of truth laravel-server-monitor (freeze and accept decay) or laravel-health (migrate and rebuild the card)? This must be decided first; it determines whether we are installing, forking, or reimplementing.
4. Does anyone expect alerting, history, or paging from a page titled "server monitor"? If yes, fix the framing before build, not after.

Integration Approach

Stack fit. The supported matrix is Nova 1.x/2.x on PHP 7.x. On Laravel 10–12 / PHP 8.2+ / Nova 4–5, treat this as a reference implementation. The decision rule is a single line of triage: run composer show laravel/nova, and if it resolves to 4.x or 5.x, stop and switch to the reimplementation path. Do not spend a day fighting Composer constraint resolution — the Vue 2/Webpack build chain is the second wall behind the first.

Migration path (where the legacy window does apply). Ordering matters and is not symmetric — collection first, presentation second:

1. composer require spatie/laravel-server-monitor, then php artisan server-monitor:install and php artisan migrate.
2. Schedule server-monitor:run-checks every five minutes with withoutOverlapping(), and force one run to confirm rows land.
3. composer require insenseanalytics/nova-server-monitor, then register the card in NovaServiceProvider::cards() — confirm the FQCN from the package's src/, since the README is thin.
4. Gate the card behind a Nova Gate (e.g. viewServerHealth) — hostnames, disk paths, and internal IPs are infrastructure detail most teams should not expose to support staff.

Compatibility and configuration surface. All real tuning belongs in config/server-monitor.php: check set, thresholds, notification routing. Thresholds in the card do nothing, because the card renders results verbatim. Custom checks are the genuine extension point — implement a Spatie CheckDefinition, register it in config, and the card renders it for free. That is how a queue-backlog or certificate-expiry check gets added without touching the Nova layer. Card poll interval must be set at or above the check cadence (≥300s against a five-minute schedule); anything tighter hammers an admin endpoint to re-read an unchanged row.

Reimplementation path for Nova 4/5 (recommended default). One read-only endpoint behind Nova middleware, one Vue 3 component of metric tiles plus a visible "last checked at" timestamp, sourced from spatie/laravel-health. Total footprint 200–400 LOC. Copy the check-to-view mapping from this package's src/ — it is small and readable in fifteen minutes — and discard the service provider, routes, and build chain. Adding the freshness timestamp here is the single highest-leverage improvement over the original: it converts a silent-stale failure into a self-diagnosing one.

Sequencing recommendation. Do not sequence this as an install. Sequence it as: (a) validate the in-admin health requirement against a specific Nova-based team; (b) settle the laravel-health vs. freeze question; (c) if a card is genuinely funded, build the thin version with a named owner; (d) only if that team is pinned to Nova 1.x/2.x, evaluate the existing package as-is. If step (a) fails — no such team — the decision has made itself and the backlog item closes for free.

Operational Impact

Maintenance. This is a permanently owned artifact regardless of path. Forking or adopting means accepting ~1–3 engineer-days per Nova major upgrade, indefinitely, plus routine attention to CSP/asset-manifest drift. The maintenance load is low in absolute terms but non-zero and unbounded in duration, which is the worst shape for a small team. Reimplementing on laravel-health trades a heavier one-time cost for a materially smaller recurring one, because the underlying source of truth stays maintained.

Support. There is no support channel. No CI, no tests, no issue triage, no security response process, and no maintainer capacity evident since 2018. Two dependencies deep, this becomes a question of who inside the org answers when it breaks — and the answer must be a person, not "the team." Budget a fork under an internal namespace with a documented owner; an unowned fork is a slower version of the same orphan risk.

Scaling. Scales by instance, not by feature. Each Nova deployment shows its own host; there is no fleet view and none is coming. Multi-tenant and agency setups work incidentally — each client's Nova displays its own box — but that is a deployment pattern, not a capability. The two real scaling limits are data volume (monitor_events grows unbounded without a retention job; add a daily prune at ~30 days) and query cost on the dashboard as that table grows. Anything resembling capacity planning, trend analysis, or SLO tracking belongs to a dedicated observability tool and should be routed there in the requirements doc, not absorbed as card scope creep.

Failure modes, roughly in order of likelihood:

• Stale-but-green. Scheduler entry missing or broken; card renders healthy because nothing is being written. Highest-frequency, highest-severity — it produces false confidence during exactly the incident it exists to shorten. Mitigation: surface last-checked, and put a runbook line in place either way.
• Wrong-tool debugging. Engineers debug the Vue component when the fault is at the artisan command or the database row. Document the backward debug order — command output → table rows → endpoint JSON → component — and save the hours.
• Installation stall. Composer constraint resolution, then CSP/manifest, then the Vue 2 build chain. Three serial walls, each plausibly a day.
• Scope confusion. A page called "server monitor" invites the assumption that alerting, history, and paging exist. They do not; alerting lives in the Spatie config and goes wherever that routes it. Label the card as a status view, not an incident channel — otherwise the first outage postmortem asks why nobody was paged.
• License lapse. Nova renewal lapsing takes the tool offline wholesale, with no graceful degradation.

Ramp-up. Low for a competent Laravel engineer: the codebase is small, the config is the documentation, and the surface area is one card plus one endpoint. Realistically half a day to read and understand, one to three days to reimplement on a modern stack, and one to two weeks if someone naively scopes it as "install and wire up" without accounting for the rewrite. The risk is not skill, it is estimation — the package looks like a plugin and behaves like a small bespoke build.

Adoption value and the honest recommendation. What this validates is real: a glanceable health card inside the admin panel saves context switches during triage — "is this slow page a disk problem or an app problem" — and it is useful as an incident-review snapshot alongside application data. What it does not justify is adoption of this code. Sixty-five stars, zero dependents, seven years of silence, and a superseded upstream are the market saying this niche is small and shrinking. It is a reference implementation and a requirements-document input, not a dependency: harvest the idea, name an owner, and if a card is genuinely funded for a specific team, build 300 lines on spatie/laravel-health rather than reviving a 2018 Vue 2 artifact.