Nova Servitor Monitor Card Laravel Package

Getting Started

The package is a Laravel Nova card that surfaces Servitor.io monitoring data (uptime, response time, status) on your Nova dashboard. There is no separate client library involved — the card is a Nova Card subclass plus a compiled Vue component.

1. Require the package:

   composer require servitorhq/nova-servitor-monitor-card
   

2. Publish any package assets/config that the service provider ships:

   php artisan vendor:publish --provider="ServitorHq\NovaServitorMonitorCard\CardServiceProvider"
   

   This is the first place to look — check config/servitor.php (or similarly named) for the API key and site/monitor ID slots.
3. Register the card in your app/Providers/NovaServiceProvider.php:

   public function cards()
   {
       return [
           new \ServitorHq\NovaServitorMonitorCard\MonitorCard([
               'api_key'  => config('servitor.api_key'),
               'site_id'  => config('servitor.site_id'),
           ]),
       ];
   }
   

4. Clear Nova's caches: php artisan nova:publish && php artisan view:clear.

The first use case is obvious: put one card on the default dashboard so the on-call developer sees a green/red badge without leaving the admin. If you want per-site monitoring, instantiate the card multiple times with different site_ids.

Before wiring anything up, verify the package installs against your Nova version. This release is from August 2018, i.e. the Nova 1.x era. Nova 2/3 changed asset registration conventions, and Nova 4/5 require Vue 3 + Vite components, so the compiled dist/ inside this card will not load on a modern Nova. Check composer.json's laravel/nova constraint before you start.

Implementation Patterns

Dashboard-only placement. The card is designed to be dropped into NovaServiceProvider::cards(). If you only want it on one dashboard rather than the main one, use Laravel\Nova\Dashboards\Main::make()->cards([...]) (Nova 2+) rather than the global method, so it doesn't pollute every dashboard.

Multi-site via multiple instances. Each card instance is bound to a single Servitor site. Rather than building a "list of sites" card yourself, just register an array:

$sites = config('servitor.sites'); // ['id' => 'label', ...]
return collect($sites)->map(fn ($id, $label) =>
    (new MonitorCard(['site_id' => $id]))->withMeta(['label' => $label])
)->all();

Credentials via config, not code. Never hardcode the Servitor API key in the provider — put it in .env and expose it through your own config/servitor.php. The package's publishable config is a starting point, but you own the file after publishing, so treat it as yours to secure.

Compose with other observability cards. The natural pattern is to place this alongside Nova's built-in Help/Welcome cards, or custom Grafana/Prometheus cards, so status indicators for "external site up" and "infra up" sit side by side. If you're already running something like Laravel Pulse or Horizon cards, this card becomes the external reachability signal that internal dashboards can't provide.

Cache the upstream call. The card's server-side data fetch is not configurable for caching as far as the published code suggests. If you're rendering it on every dashboard load for several sites, wrap the underlying HTTP client call in a Cache::remember(..., 60, ...) via a small subclass of the card, or accept the extra latency.

Gotchas and Tips

• Nova compatibility is the main blocker. 2018 means Nova 1.x. Test asset loading explicitly — if the card renders as an empty grey block, the compiled JS never registered with the current Nova asset pipeline. You'll need to fork and rebuild the Vue component against the Nova version you run (see the Nova docs on custom card tooling).
• Naming mismatch. The repo is nova-servitor-website-card while the package is nova-servitor-monitor-card. Double-check you're composer require-ing the right name and vendor before debugging "class not found."
• Assets not publishing. For Nova 1/2 cards, assets land under public/vendor/.... Run php artisan nova:publish and confirm the compiled JS appears there; a stale public/vendor after upgrades is a classic cause of blank cards.
• API key exposure. If the card fetches Servitor directly from the browser (rather than proxying through the card's controller), the API key is in the response payload. Check the Vue source in the published dist/ — grep for axios/fetch — and, if it does, wrap it server-side.
• No error states. Small 2018 packages rarely handle upstream 4xx/5xx gracefully. Add a wrapper subclass overriding the data-fetch method to return ['status' => 'unavailable'] on failure, otherwise one Servitor outage takes the whole dashboard section down with a JS console error.
• Servitor.io service existence. Verify the upstream API is still live before depending on this. If Servitor has since changed endpoints or auth, the card is dead-on-arrival and your options are: fork the card, or replace it with a simple custom card hitting whatever uptime provider you actually use.
• Extension points are thin. The realistic extension path is a subclass overriding the API call and metadata, plus a rebuild of the Vue side. Given 5 stars and zero dependents, budget for a fork rather than upstream PRs.