Filament Service Pinger Laravel Package

Getting Started

Before you install, check the source. With 0 stars and 0 dependents, treat this as an unvetted internal package: open src/ and composer.json on GitHub first and confirm the Filament major version it targets (v3 vs v4), the PHP constraint, and whether it ships migrations, a config file, or both. If anything looks stale, budget an hour to fork it — it is MIT and small enough to own outright.

Minimal path for a Filament v3 panel:

1. composer require yugo/filament-service-pinger (pin the exact version you test with — there is no ecosystem pressure keeping the API stable).
2. Publish assets if the README says so: php artisan vendor:publish --tag="filament-service-pinger-migrations" and --tag="filament-service-pinger-config". Many Filament plugins auto-load migrations; verify by checking whether the service provider calls loadMigrationsFrom.
3. php artisan migrate.
4. Register the plugin on the panel you actually want it on (usually an admin/ops panel, not a customer-facing one):

public function panel(Panel $panel): Panel
{
    return $panel
        // ...
        ->plugin(ServicePingerPlugin::make());
}

5. Visit the panel — a nav group should appear with the monitor resource. Create one monitor against something you control (a staging health endpoint, not https://example.com, which will give you a permanently green result and teach you nothing).
6. Find the execution path. Uptime monitors are useless without a scheduler, so before you go further run php artisan schedule:list and grep the package for Schedule, Command, or Job classes. If the package registers a scheduled command, make sure schedule:run is actually running in your environment (cron or php artisan schedule:work locally).

First use case: a two-monitor sanity check — one endpoint you know is up and one you temporarily point at a dead host — to confirm the plugin records down state, renders a red badge, and fires whatever notification it claims to support. Do this before wiring up real services; you want to learn the failure behavior while the blast radius is zero.

Implementation Patterns

Deploy-synced monitors from config, not clicks. Creating monitors in the UI is fine for a demo, but production monitor definitions belong in version control. Pattern: keep an array in config/services-monitored.php, write a small php artisan monitors:sync command that updateOrCreates rows keyed on URL, and call it from your deploy script. This gives you reviewable diffs, per-environment URL differences, and recovery if someone deletes a record.

Dedicated ops panel. Do not attach the plugin to the same panel your end users log into. Create (or reuse) an internal panel, put the plugin there, and gate it with canAccessPanel() against an admin role or an email allowlist. Monitor rows often contain internal hostnames, query strings with tokens, and basic-auth credentials — that is not data you want behind a generic user guard.

Queue the checks. If the package's scheduled command runs checks synchronously, a single hanging endpoint can stall the whole schedule run. Wrap it: override the check job's connection/queue in config, or if the package does not queue, write your own CheckAllMonitors job that dispatches per-monitor jobs with ->timeout(10) and ->withoutOverlapping(). Either way, run a worker. Silent failure mode: scheduler fires, job sits in the queue, dashboard shows stale-but-green status forever.

Widgets on an existing dashboard. Rather than sending people to a plugin-specific page, register whatever widget the package exposes onto your main admin dashboard:

->widgets([
    \Yugo\FilamentServicePinger\Widgets\ServiceStatusWidget::class,
])

Check the actual class names in src/Widgets — the namespace above is a guess. Combine with Filament's ->columns(2) so it sits next to your other operational stats.

Flap suppression. A single failed check should not page anyone. If the package doesn't ship a consecutive-failure threshold, implement it yourself: keep consecutive_failures on the monitor row, increment/reset on each result, and only dispatch the "down" notification when the count crosses 2–3. This is the difference between a tool your team trusts and one they mute.

Alerting hand-off. Don't rely on the package's built-in notification channel if it is thin. Listen to model events or poll results and forward to your existing alert path:

MonitorDown::class => [NotifyOnCallChannel::class],

If the package uses plain Laravel notifications, you can also swap the notification class via config or by extending the service provider. Verify which by reading the source; there is no documented extension API at this adoption level, so treat "extend" as "fork or subclass a concrete class."

Local development and tests. Point monitors at Http::fake() responses in tests and disable the scheduler in .env locally (MONITOR_ENABLED=false or whatever flag exists, otherwise your laptop will hammer staging every minute and you'll get paged at 3am by yourself). For Livewire tests of the resource, use Filament's testing helpers (livewire(MonitorResource\Pages\ListMonitors::class)->assertCanSeeTableRecords(...)) and check the resource class names in src/Resources.

Multi-tenant panels. If your panel is tenanted, confirm the monitors table has a tenant_id-equivalent and the resource scopes getEloquentQuery(). Most small plugins do not handle tenancy out of the box — you'll be adding a tenant_id migration and an observe/scope yourself. If that is your situation, this package is a starting point, not a solution.

Gotchas and Tips

• Zero stars is the headline risk. No dependents means no one else has hit the upgrade bugs for you. Pin "yugo/filament-service-pinger": "1.0.x" (or a commit hash) in composer.json, and add a composer update guard in CI. Read the diff on every bump.
• Scheduler looks broken when it isn't. "Monitors never update" is almost always cron, not the package. Check schedule:list includes the package's command, check storage/logs for schedule:run output, and check failed_jobs. Add onOneServer() and withoutOverlapping() to the schedule entry if the package doesn't.
• Redirects and status-code semantics. A 301 to a healthy page is not "down," and a 200 on a login page is not "service healthy." Look for a configurable "expected status" field; if it only stores "any 2xx," be aware deep health checks are out of scope and you'll want a separate synthetic-check tool.
• SSL verification. Common quick fix during setup is disabling TLS verification — don't ship that. If an internal service uses a private CA, add the CA bundle path to the HTTP client config rather than setting verify => false.
• Secrets in the database. Basic-auth passwords or API tokens stored on a monitor row are plaintext unless the package casts them as encrypted. Check the model's $casts. If they aren't encrypted, add the cast yourself — it's a one-line migration-safe change.
• Result-table growth. Every check writes a row. N monitors × every minute × 90 days is a real table. Configure Prunable/MassPrunable on the results model (or write a model:prune entry) before this becomes someone's incident.
• Timezone and clock skew. Check timestamps against config('app.timezone') vs the DB's UTC storage before you conclude checks are late. updated_at looking stale by hours is usually a rendering issue, not a monitoring outage.
• Migration collisions and table prefixes. Table names are unprefixed in most small plugins (monitors, monitor_results). If you already have a monitors table, publish and rename in the migration before running it, or you'll fight a half-applied migration.
• No canAccess on the resource means everyone sees it. Audit the resource's canViewAny/policy wiring on day one, especially on a shared admin panel.
• Extension points to look for in src/: a Config class with ->enableX() fluent methods (the Filament plugin convention), the check job class (override via container binding), the notification class (swap in config), and the resource class (replace with ->resource(YourResource::class) if you need custom fields). If none of those exist, your extension strategy is vendor:publish + subclass, and you should note that in your team's README so the next person doesn't re-derive it.
• Debugging a check: bypass the UI entirely. Run the package's command manually with -v, or Http::get() the target from php artisan tinker in the same environment. Nine times out of ten the service is fine and the container's egress or DNS is not — the plugin is just the messenger.