Nova Server Monitor Laravel Package

Getting Started

Establish the preconditions before touching the card. This package is a presentation layer with no collection of its own — it renders rows that spatie/laravel-server-monitor already wrote. Confirm three things in order:

composer show laravel/nova                    # 1.x or 2.x only
composer show spatie/laravel-server-monitor   # the data source
php -v                                        # 7.1/7.2 era

If Nova resolves to 4.x/5.x or PHP to 8.x, stop the install attempt and switch to the reference-implementation pattern below. The Vue 2/Webpack bundle is the second wall after the Composer constraint failure, and you will hit both.

Install the collector first, the card second.

composer require spatie/laravel-server-monitor
php artisan server-monitor:install
php artisan migrate

composer require insenseanalytics/nova-server-monitor

Register the card in app/Providers/NovaServiceProvider::cards(), reading the package's src/ for the exact FQCN — the README is thin and the namespace does not always match the package name:

public function cards()
{
    return [
        new \Insenseanalytics\NovaServerMonitor\NovaServerMonitor,
    ];
}

Prove the pipeline runs before you judge the card. A card reading an empty table looks identical to a healthy server.

// app/Console/Kernel.php
$schedule->command('server-monitor:run-checks')->everyFiveMinutes()->withoutOverlapping();

php artisan server-monitor:run-checks
php artisan tinker --execute="dump(DB::table('monitor_events')->latest('created_at')->first());"

Only then load /nova.

First use case to wire: put the card on the dashboard next to your resource metrics and treat it as a triage glance — "is this slow page a disk problem or an app problem?" — answered without an SSH session. That is the entire value proposition. The moment you want history or a graph, you are in the wrong tool.

Implementation Patterns

Match the card's refresh cadence to the scheduler, not to your patience. The card polls an admin endpoint; the scheduler writes rows every N minutes. Polling faster re-reads the same row and burns admin requests.

$schedule->command('server-monitor:run-checks')->everyFiveMinutes()->withoutOverlapping();
// card refresh interval: >= 300s

Gate visibility behind a Nova gate. Hostnames, mount paths, and internal addressing are infrastructure detail that support and sales-adjacent staff rarely need:

public function cards()
{
    return Gate::allows('viewServerHealth')
        ? [new \Insenseanalytics\NovaServerMonitor\NovaServerMonitor]
        : [];
}

Check the card class for an authorization hook first — a gate evaluated inside the card is cleaner than emptying the whole dashboard array.

Tune thresholds in config/server-monitor.php, never in the Nova layer. The card renders check results verbatim; changing the frontend only changes how you mis-read the same verdict.

'checks' => [
    Spatie\ServerMonitor\CheckDefinitions\Diskspace::class => [
        'options' => ['thresholds' => ['warning' => 80, 'failure' => 90]],
    ],
    Spatie\ServerMonitor\CheckDefinitions\LoadAverage::class => [
        'options' => ['thresholds' => ['warning' => 3, 'failure' => 5]],
    ],
],

Add checks via Spatie's CheckDefinition, not via Nova. Implement the definition, register it in config, and the card displays it for free because it is a generic result table. This is the cheapest way to fold in queue backlog, certificate expiry, or a cache ping.

Schedule retention on day one. Server Monitor does not prune. On a long-lived install the results table grows without bound and the card's query degrades silently:

$schedule->call(fn () => DB::table('monitor_events')
        ->where('created_at', '<', now()->subDays(30))
        ->delete())->daily();

Snapshot at incident time. Because there is no history, capture the card (or the endpoint JSON from the network tab) into the incident doc while you are looking at it. That single habit is what makes this card worth having during a postmortem.

Reference implementation for Nova 4/5. If you are building rather than adopting, the shape is small and you own it:

// routes/api.php
Route::middleware(['nova'])->get('/nova-vendor/server-health', HealthController::class);

// NovaServiceProvider::boot()
Nova::script('server-health', __DIR__.'/../dist/js/card.js');

The controller returns the latest result per check from a maintained source (spatie/laravel-health → Health::latestResults()); the Vue 3 component is a tile grid plus a "last checked" timestamp. Copy the check-to-view mapping from this package's src/, discard its service provider, routes, and build chain. Budget 200–400 LOC.

Gotchas and Tips

"Real-time" means "whatever the last check wrote." The card runs nothing. The dominant failure mode is a missing or broken scheduler entry producing a serene, permanently green dashboard. Verify monitor_events has a recent timestamp before debugging any UI symptom.

Freshness is invisible in the 2018 UI. There is no prominent "last checked at" marker, which converts a stale-data bug into a silent lie. If you fork, add the timestamp — it makes the card self-diagnosing for the cost of one line in the endpoint.

Debug backwards through four layers. Artisan command output → database rows → the card's JSON endpoint in the network tab → the Vue component. Nearly every bug lives in layer one or two, and developers reflexively start at layer four.

It will not install on a modern stack. Nova 4 replaced the npm-mixin tool registration with Nova::script()/Nova::style() and moved the asset pipeline to Vite + Vue 3. Treat any "just composer require" estimate as unvalidated; the honest estimate is a rewrite.

CSP and asset-manifest breakage come after Composer clears. A strict Content-Security-Policy or a mismatched mix-manifest.json will produce a blank card with a clean console. Budget for it.

No tests, no CI, single maintainer, last release 2018-12-08, zero dependents. There is no security response channel and no upstream fix in flight. If you adopt it, fork it and put a name against it — otherwise it orphans at the next team change. Assume 1–3 engineer-days per Nova major upgrade, indefinitely.

Two legacy dependencies, not one. laravel-server-monitor is superseded by spatie/laravel-health. Settle the source-of-truth question before you fork the card: standardize forward on laravel-health, or freeze Server Monitor and accept the decay. Do not fork and inherit both problems unexamined.

Nova's license is the real cost center. ~$199/site plus renewals dwarfs a 65-star status card. This package only ever rides along on a Nova license you already justified on other grounds.

Scope confusion is the political failure mode. A page titled "server monitor" invites assumptions of alerting, history, and paging — none of which exist here. Alerting lives in the Spatie config and goes wherever that sends it. Label the card explicitly as a status view, or you will be asked why nobody was paged.

Do not grow trend analysis here. No storage, no graphs, no SLO tracking. A request for CPU over time is answered by your observability tool, not by extending this card.