Nova Server Metrics Laravel Package

Getting Started

llaski/nova-server-metrics is a Nova dashboard card that surfaces host-level CPU, memory and disk figures inside the Nova UI. Version 1.2.0 adds Nova 4 support, so the first thing to do is confirm which Nova major you are on before you install.

# Nova 4.x
composer require llaski/nova-server-metrics:^1.2

# Nova 3.x — stay on the previous line unless the constraint allows both
composer require llaski/nova-server-metrics:^1.1

Check composer.json in the package (or run composer why-not llaski/nova-server-metrics 1.2.0) rather than assuming 1.2.0 is a dual-support release; this was a Nova 4 compatibility PR, and the illuminate/* / laravel/nova constraints are the source of truth.

Registration happens in app/Providers/NovaServiceProvider.php, inside dashboards():

use Llaski\NovaServerMetrics\ServerMetrics;

protected function dashboards()
{
    return [
        Main::make()->cards([
            ServerMetrics::make(),
        ]),
    ];
}

Publish the config and assets once, then re-run the asset publish after the upgrade:

php artisan vendor:publish --provider="Llaski\NovaServerMetrics\NovaServerMetricsServiceProvider"
php artisan nova:publish

Where to look first: the card's Vue component under resources/js (to see exactly which endpoint it hits and how often), then the config file for thresholds. The first real use case is a single card on the Main dashboard giving you at-a-glance headroom on the box — useful right before you decide whether a deploy, a queue worker bump, or a composer update is safe.

Implementation Patterns

Threshold-driven visual states. Rather than reading raw percentages off the card, configure warn/critical breakpoints so the card turns amber/red. This turns it into a passive alerting surface you actually notice during normal Nova usage, without standing up Prometheus.

Environment-gated registration. Host metrics are noise on local Herd/Valet machines and can be misleading in CI. Register the card conditionally:

Main::make()->cards(array_filter([
    app()->isProduction() ? ServerMetrics::make() : null,
]))

One card per concern on a dedicated "Ops" dashboard. Keep the main dashboard human-focused and put CPU/RAM/disk cards on a separate dashboard restricted via Nova::dashboards() authorization callbacks. This keeps the refresh polling of the metrics endpoint off the page every admin lands on.

Correlate with deploy windows. Because the card is a live point-in-time read, the practical workflow is: deploy → open the Ops dashboard → watch memory settle back down. If it does not return to baseline, you have a leak or orphaned workers. Pair the card with a scheduled php artisan queue:monitor or Horizon so you have both instantaneous and historical signals.

Reuse the probe in health checks. If you need the same numbers outside Nova, wrap the underlying collection logic in your own service and use it both for a custom card and for a /up style endpoint — avoids two divergent implementations of "how much disk is left".

Upgrade path for Nova 3 → 4 shops. The 1.2.0 bump is the moment to upgrade Nova and this card together. Bump Nova first, then this package, then run php artisan nova:publish and hard-refresh; Nova 4's compiled assets are a common source of "card renders blank" reports that have nothing to do with this package.

Gotchas and Tips

• The numbers describe the PHP host, not your fleet. On load-balanced or multi-node deployments the card reports whichever node served the Nova request. It is not an aggregate. Don't use it to judge cluster capacity.
• Containers lie. Inside Docker/Kubernetes the card typically reads host /proc or sys_getloadavg() values rather than the cgroup limit, so a container capped at 512 MB can happily report the node's 64 GB. If you run in containers, treat memory numbers as indicative only, or read memory.limit_in_bytes yourself.
• Permissions and disabled functions. Collection relies on shelling out or reading system files. shell_exec/exec in disable_functions, open_basedir restrictions, or SELinux policies will silently yield empty/zero values instead of throwing. If the card renders but everything is 0, check php -i | grep disable_functions first.
• Polling and caching. The card re-requests its endpoint on an interval; a short interval on a busy admin panel adds load. If values look stale, look at the component's refresh prop and any response caching in front of Nova rather than assuming the metrics are wrong.
• Authorization is inherited, not built in. The metrics endpoint sits behind Nova's middleware, so anyone with Nova access sees host internals (disk paths, load averages). That is usually fine, but be deliberate about who gets the dashboard.
• Debugging route. Open the browser network tab, find the card's XHR, and replay it with curl using a Nova session — the response body usually contains the raw exception. Cross-check storage/logs/laravel.log for the same timestamp.
• Extension points. Subclass the card or bind your own metrics collector in the container if you need to add GPU, swap, or per-disk breakdowns; overriding the Vue component via Nova::script() is cleaner than editing vendor files, which composer update will discard.
• Semver discipline. 1.2.0 is a minor release with no documented breaking changes, but the Nova 4 support may have moved the laravel/nova constraint upward. Pin the version in composer.json (rather than floating ^1.0) so a future Nova 5 bump doesn't take your dashboard down mid-sprint.