Product Decisions This Supports
- Internal admin/ops tooling roadmap: Informs whether your Nova-based back-office can surface live server health (CPU load, memory, disk usage) to operators and support teams without building a bespoke monitoring UI.
- Build vs. buy for observability surface: Helps decide whether to keep lightweight in-app metrics (this package, a few lines of config) versus investing in a dedicated APM/observability vendor (Datadog, New Relic, Grafana) — this package is the cheap, low-fidelity option scoped to Nova users only.
- Admin panel platform strategy: The 1.2.0 release explicitly adds Nova 4 support, which means the package is a viable dependency if your roadmap includes upgrading Nova 3 → Nova 4. It removes a compatibility blocker from that migration epic.
- Support/on-call workflow design: Enables a "first responder checks the dashboard" workflow for non-engineers, reducing escalation latency for simple capacity issues.
- Scope boundaries: It is a read-only visibility widget, not alerting, not historical trending, not multi-tenant. Do not let it substitute for real incident alerting on the roadmap.
When to Consider This Package
Adopt when:
- You run Laravel Nova (3.x or, as of 1.2.0, 4.x) and want server metrics visible inside the admin panel with near-zero integration cost.
- The audience is internal operators/administrators who already have Nova access — no new auth surface or tool to procure.
- You need coarse, current-state metrics (load average, memory, disk), not time-series history.
- Budget/approval friction rules out a monitoring SaaS for a small internal use case.
Look elsewhere when:
- You are not on Nova, or you are on a Nova version outside the supported range — this is a single-maintainer package with a thin release cadence (1.1.0 → 1.2.0 tracked a Nova major), so version support arrives reactively, not proactively.
- You need alerting, retention, dashboards over time, or per-node fleets — use Prometheus/Grafana or a hosted APM.
- You have multi-server or containerized/ephemeral infrastructure where
exec-style host metrics are misleading or unavailable.
- You require vendor SLA, security review, or long-term maintenance guarantees; the dependency is community-maintained by one contributor.
- You operate in a regulated environment where shelling out for system metrics from the web tier fails policy review.
Migration note: if you are already on this package and planning the Nova 4 upgrade, 1.2.0 is the enabling version — sequence the Nova upgrade and this bump together and validate metric collection in staging, since Nova 4 changed asset/tooling conventions.
How to Pitch It (Stakeholders)
To executives: This is a small, free, community add-on that puts basic server health — CPU, memory, disk — on a screen our administrators already use. It costs effectively nothing to adopt and gives operations staff a fast first look before escalating. It is visibility only: it does not page anyone, keep history, or replace our monitoring vendor. Treat it as a convenience layer for internal users, not a system of record.
To engineering: The 1.2.0 release adds Nova 4 support, so this is now compatible if we proceed with the Nova 4 upgrade — that removes one blocker from the migration backlog. Integration is config-only; no schema, no migrations, no new service. Two caveats to accept explicitly: it is a single-maintainer dependency with reactive version support, and host-level metrics can be inaccurate in containerized or autoscaled environments. Recommendation: adopt as an internal convenience widget, keep our real alerting where it is, and if we upgrade to Nova 4, bundle this bump into that workstream so we validate it once rather than twice.