Filament Uptime Monitor Laravel Package

Technical Evaluation

What this release is. v1.0.1 is a security-hardening and correctness release, not a feature release. There is no new capability to sell internally; the value is in closing an SSRF hole in the manual "Check now" action and in fixing two defects that produced misleading signal.

Architecture fit. The package is a Filament panel plugin layered on spatie/laravel-uptime-monitor. It owns presentation (Filament resources/widgets), the manual check action, and a bulk-check entry point; scheduling, persistence, and notification semantics belong to the upstream Spatie package. This is a good fit only where the team is already standardised on Filament and needs a lightweight operator surface over a small number of HTTP checks. It is not a monitoring engine and should not be positioned as one — there is no probe distribution, no multi-region vantage point, and no synthetic transaction support.

Integration feasibility. Composer-level and cheap: one package, one command. The real work is not installation but verification, because this release's fixes are the kind that pass silently when absent (see risk below).

Technical risk.

Test evidence. Reasonable for a package of this size: static analysis at PHPStan level 5, 82 Pest tests across PHP 8.2–8.5 × Laravel 12/13 × Filament 4/5, plus a 45-check headless-Chrome UI pass in light and dark, and a clean-cache install from Packagist on both version pairs. The UI suite now includes a pinned check of a public site with private hosts blocked — that is the right test to have added. Note the gap: no negative test against a load-balanced or CDN-fronted host is described, which is precisely where pinning is most likely to surprise.

Key questions for the maintainer / our team.

1. What are the actual bulk-check cap and per-user rate limit? They are now documented in the README but not quoted in these notes — we need the numbers to size operator expectations.
2. How should we monitor internal/private hosts now that "Check now" refuses private addresses?
3. Does a custom request action inherit any guard at all, or is it fully bypassed?
4. What is the fallback if a host resolves to multiple addresses — is one pinned, or is the set handled?

Integration Approach

Stack fit. Laravel 12 or 13, PHP 8.2–8.5, Filament 4 or 5, Guzzle 7 (a hard requirement of spatie/laravel-uptime-monitor 4.7.x, and the most likely source of transitive churn). The tested matrix is current and wide enough that most estates will land inside it. Anything on Filament 3 or PHP 8.1 is out of scope and should be treated as a separate decision.

Migration path. composer update amjadiqbal/filament-uptime-monitor, adding -W on Laravel 13 as for the initial install. No deprecations, no configuration migration, no data migration are announced. The only substantive change is the transitive requirement bump on the Spatie package — with -W this may resolve more of the dependency graph than intended, so review the full composer.lock diff rather than just the plugin's own version.

Compatibility. Two axes to check:

• Upstream Spatie version. Anything below 4.7 is both unsupported and, per the release notes, was previously running an inert guard. This is the single blocking compatibility item.
• Filament major. Filament 4 and 5 are both tested, but the version pairs in CI are specific (4.15.3 and 5.10.3). Confirm your exact Filament patch level is at or above those before assuming the UI test results transfer.

Sequencing.

1. Inventory — lockfile audit for Spatie 4.6 anywhere in the estate, plus a list of monitors using custom request actions. Both feed the risk register directly.
2. Stage — update with -W off, then with it on, and diff the lockfile.
3. Verify, don't assume — the 4.6 failure mode was silent, so a green pipeline proves nothing about whether the redirect guard is actually active. Assert the resolved Spatie version explicitly in CI.
4. Behavioural validation — run the pinned check against your real endpoints: CDN-fronted, load-balanced, TLS-terminated at an edge, and anything behind a proxy. Add a private-address host to confirm the refusal path behaves as documented.
5. Notification dry run — confirm an unresolvable host produces one alert, not an alert storm, before promoting to production.
6. Production, then README update — align internal runbooks with the newly documented guard scope, cap, and rate limit.

Operational Impact

Maintenance. Low ongoing effort, but the dependency posture has tightened. The plugin now depends on a specific upstream class shape, so an upstream minor release can break the guard. Budget for a monthly version check rather than a set-and-forget assumption. The plugin's own release cadence looks disciplined (security fix, doc fix, CI evidence in one patch release), which is a good signal for a package sitting in an admin panel.

Support. Net improvement. The README now states the exact bulk-check cap, the per-user rate limit, the guard's coverage boundaries, and the Guzzle 7 requirement — all four are classic first-week tickets. Support should point at the documented scope rather than treating "the guard didn't fire for my custom action" as a defect. Expect one predictable class of ticket regardless: users who cannot "Check now" an internal host.

Scaling. Bounded by the bulk-check cap and per-user rate limit, which is appropriate — an admin button that can fan out to unbounded outbound requests is an availability risk in its own right. Get the actual numbers before publishing operator guidance. Beyond those limits, scale is an upstream Spatie question, not a plugin one.

Failure modes to instrument.

• Silent guard regression — the 4.6 pattern. Highest severity, because it is invisible. Assert the upstream version at boot or in CI.
• Pinned-IP mismatch — CDN or load-balanced hosts where the pinned address is not the one the edge expects. Symptom: intermittent failures that correlate with DNS rotation rather than with actual outages.
• Resolver blips — now surface as "Could not resolve host" / down. Tune alerts so a single NXDOMAIN does not page.
• Coverage gaps — custom request actions and the certificate check's connection sit outside the guard. Any internal-facing use of either needs network-level egress controls as the real boundary.
• False scheduler alarms — fixed. The hint now uses the shortest interval among enabled monitors, so long-interval monitors no longer trigger it. This removes a recurring, credibility-eroding false page; worth calling out to on-call as a quality-of-life win.

Ramp-up. Low for a Laravel developer — a Composer update and a Filament panel registration. The non-obvious knowledge is concentrated in two places: the guard's scope boundaries, and the fact that the previous release could look healthy while the guard was inert. Put both in the runbook. On-call needs a one-paragraph briefing covering the new DN"S-unresolvable-means-down semantics and the private-address refusal, since both change what a "down" alert means in practice.