Filament Uptime Monitor Laravel Package

Getting Started

This is a Filament panel plugin that puts a UI on top of spatie/laravel-uptime-monitor: you get a resource to create/monitor URLs, a "Check now" action, uptime/latency history, and a scheduler health hint — without writing your own CRUD or uptime plumbing.

Minimal path:

1. composer require amjadiqbal/filament-uptime-monitor — on Laravel 13 add -W (same as the install docs). This pulls spatie/laravel-uptime-monitor ^4.7, which in turn requires Guzzle 7.
2. Publish and run the vendor migrations (and config, if you want to tune intervals/notifications), then php artisan migrate.
3. Register the plugin on the panel you want it in, inside that panel's PanelProvider::panel() chain — not globally, unless you want it on every panel.
4. Make sure the Laravel scheduler is actually running (* * * * * php artisan schedule:run or schedule:work), and that a queue worker is up if checks are queued. The plugin will tell you if the scheduler looks dead — that hint is one of the first things you'll see.
5. First use case: create a monitor for your public marketing/app URL with a 5-minute interval, hit Check now to verify it goes green, then let the scheduler take over.

Look first at the plugin's config (intervals, timeouts, notification channels) and at the Spatie uptime-monitor config it sits on top of — the plugin is a thin Filament layer, so most behaviour you'll want to change lives in Spatie's config and models.

Implementation Patterns

Panel-scoped registration. Register the plugin only on the admin/ops panel. It exposes monitor management and a "Check now" button; you generally don't want either on a customer-facing panel.

Treat "Check now" as a manual escape hatch, not the mechanism. Day-to-day uptime comes from the scheduler + queue. Use the button when onboarding a new monitor, after changing a URL, or when debugging an alert. Because of the v1.0.1 fix, a manual check now resolves the host once, refuses private addresses, and pins the request to that resolved IP — so a manual check is a realistic-but-safe probe of what the scheduled check will do.

Extend Spatie's request action for custom probes. If you need auth headers, a specific path, a POST, or custom assertions, subclass the package's request action rather than replacing the whole check. Note the v1.0.1 constraint: the redirect guard extends that action and only works on spatie/laravel-uptime-monitor >= 4.7.0 — on 4.6 the guard silently did nothing. Pin ^4.7 explicitly in composer.json rather than relying on transitive resolution, and re-verify after any Spatie major/minor bump.

Custom request actions are outside the SSRF guard. The address guard covers the built-in check only. If you write your own action that takes a user-supplied URL, you own the private-address rejection and DNS pinning — replicate the resolve-once / reject-private / CURLOPT_RESOLVE pattern rather than assuming the plugin did it for you. Same for the certificate check, which opens its own connection.

Respect the bulk-check cap and per-user rate limit. The README states the exact numbers; the practical pattern is to let ops users bulk-check a handful of monitors after an incident, and to keep the cap low enough that a mis-click can't fan out into hundreds of outbound requests. If you're tempted to raise them, remember every check is an outbound HTTP request from your app server.

Scheduler hint tuning. The "Is the scheduler running?" hint keys off the shortest interval among monitors that are on. If you disable your fast monitors, the hint threshold moves with them. Keep at least one low-interval monitor enabled if you rely on that hint as your only scheduler canary — or better, add a real schedule:list-based heartbeat of your own.

Environment separation. Because private/reserved addresses are refused, staging and internal-only monitors will legitimately report down. Keep internal monitors in a non-production panel/environment, or don't add them at all — don't weaken the guard to make a dev URL go green.

Gotchas and Tips

• Silent dependency failure is the headline risk. On spatie/laravel-uptime-monitor 4.6.x the redirect guard no-ops with no error. If you upgraded this plugin but pinned Spatie down, your redirect protection is gone and nothing tells you. Check composer show spatie/laravel-uptime-monitor after every lockfile change.
• Guzzle 7 is mandatory via Spatie 4.7.x. If another package pins Guzzle 6, you'll get resolution conflicts — resolve those before upgrading, not after.
• "Could not resolve host" is now a down state, not a skipped check. Transient DNS blips will show as downtime. If your DNS is flaky, expect occasional red and check whether it's DNS or the app before paging anyone.
• DNS pinning and redirects interact. The request is pinned to the checked address; a redirect to a different host is a new resolution. Test any monitor that redirects across hosts (e.g. apex → www, or a CDN edge) and confirm the outcome is what you expect.
• Scheduler vs. queue confusion. Monitors look "stuck" most often because the scheduler isn't running or the queue worker is dead — not because the check failed. The hint covers the former only; watch failed_jobs for the latter.
• Config caching. After changing plugin or Spatie config, php artisan config:clear (or re-cache) — cached config is the usual explanation for "my interval change did nothing".
• Extension points, in order of preference: config values → custom request action subclass → your own Filament resource if you outgrow the UI. Avoid editing published vendor views/migrations, since the 1.0.x line is still moving.
• Tested matrix is broad (PHP 8.2–8.5, Laravel 12/13, Filament 4/5) but the pinned end-to-end UI run was on Laravel 12.70.1 + Filament 4.15.3 and Laravel 13.38.0 + Filament 5.10.3. If you're on an older Filament 4 minor, do a quick smoke test of the resource page and the "Check now" action after upgrading.