Filament Health Dashboard Laravel Package

Technical Evaluation

Architecture fit This is a thin presentation layer over spatie/laravel-health — no migrations, no persistence, no new datastore, no queue workers. It reads the health check registry at runtime and renders it inside Filament. That is a low-blast-radius shape: it can be added to an existing panel and removed without residue. The three-surface design (standalone page, widget, embeddable <livewire:filament-health-dashboard />) is the strongest architectural signal — one install can serve an ops-only dashboard, a panel home widget, or an inline embed on an existing page, which removes a class of bespoke blade work teams typically write themselves. The CheckIntegration layer is the meaningful extension point: it lets us attach rich per-check tables and remediation actions without forking the package, which is the difference between a demo and something we can own.

Integration feasibility Install is a composer require plus plugin registration in a panel provider. The inlined stylesheet removing the php artisan filament:assets step is a genuine operational win — that step is a recurring source of "works locally, unstyled in prod" failures and of deploy-pipeline special-casing. The hard constraint is Filament v4 only. Any panel still on v3 is excluded outright, and v4 itself is early enough that the surrounding ecosystem (other plugins, custom panel themes) may not be fully migrated. We should treat this as usable only in panels already committed to v4.

Technical risk

• Pre-1.0 API surface. v0.1.0 carries no compatibility promise. The CheckIntegration contract, config keys, and component names should all be assumed to move.
• Generic Result->meta rendering is a data-exposure risk, not just a feature. Auto-rendering scalars, nested JSON, and record tables means whatever a check puts in meta — connection strings, hostnames, env values, exception traces — becomes visible to anyone who can see the dashboard. This needs a policy decision before enablement, not after.
• Inlined CSS. Convenient, but it conflicts with a strict style-src CSP and duplicates payload if the widget is embedded more than once per page.
• Auto-refresh polling. Every polled viewer re-triggers check execution; cost scales with viewers × interval × per-check expense.
• Remediation actions. Authorization and debounce are present and advertised, but the authorization hook needs to be wired to our own gate — the package can only enforce what we configure.

Key questions

1. What are the exact Filament, Livewire, Laravel, and PHP version constraints, and is a Filament v3 path planned?
2. Is there a documented gate/policy contract for viewing the dashboard, or only for running remediation actions?
3. Does "re-run checks" execute checks synchronously in the request, or re-read cached results? What is the worst-case latency on a check that makes outbound HTTP calls?
4. Can auto-refresh be disabled globally and per-surface, and what is the default interval?
5. Is meta rendering filterable/allowlisted per check, or all-or-nothing?
6. Does inlined CSS respect a nonce-based CSP, or is it unconditional <style> injection?
7. Does it support multiple panels, and does the failing-count badge behave correctly for users who can see some panels but not others?
8. Is CheckIntegration considered stable, and are there published examples beyond the source?
9. Does it coexist with laravel-health's own scheduling and notification channels without double-reporting?

Integration Approach

Stack fit Best fit is a Laravel app already running spatie/laravel-health with at least one Filament v4 panel. If health checks exist but the panel is v3, this is not adoptable today. If neither exists, the package is not a reason to introduce either dependency — sequence it after health checks are already valued.

Migration path Greenfield, no data migration. The realistic "migration" is retiring hand-rolled health blade views or ad-hoc /health JSON polling dashboards once parity is demonstrated. Keep those in place until the package has run a full on-call cycle, since it changes how operators see failures, not just the cosmetics.

Compatibility Treat the dependency as pinned-exact, not caret-ranged, for the first few months. Verify Livewire alignment with the panel's Filament v4 minor, and confirm laravel-health's version constraint in the package's composer.json rather than assuming latest. Test with our actual CSP headers in staging — that is the most likely silent breakage.

Sequencing

1. Confirm target panel is on Filament v4 and health checks are already running.
2. Branch install, register the plugin on a non-default panel first.
3. Define and wire the view authorization gate; decide the meta exposure policy per check.
4. Staging deploy with production-equivalent CSP and asset pipeline.
5. Choose surface deliberately: page for ops, widget for general panel users, embed for narrow contexts.
6. Ship with auto-refresh off; enable per-panel after measuring check cost.
7. Implement CheckIntegration adapters for the top 3–5 checks that actually page people — this is where the value compounds.
8. Promote to the ops panel; keep the legacy view for one on-call rotation.

Operational Impact

Maintenance Ongoing cost is dependency-tracking, not code. A 0.x package with no deprecation policy means each minor release is a potential break; budget a review per release and pin versions in between. Secondary cost: we now depend on Filament v4's release cadence, so a Filament major becomes a two-package upgrade rather than one.

Support Community-supported, likely small maintainer footprint. Internal escalation realistically means reading the source. Mitigate by keeping our CheckIntegration implementations in our own codebase, not as patches to the vendor package — that is the only part we genuinely own.

Scaling The scaling axis is polling fan-out, not data volume. Cost ≈ (concurrent dashboard viewers) × (refresh interval) × (cost of every registered check). Checks that hit the network, database, or Redis are the expensive ones and they run because someone left a tab open. Default to manual re-run on shared/large screens; reserve auto-refresh for a single ops display with a long interval.

Failure modes

• Stale-green: results are cached reads; a check that stopped running looks healthy. The package prevents false success notifications on action, not staleness of the underlying data.
• Silent unknown: a check that throws during execution may render as an unremarkable cell rather than an alert — verify the unknown/error visual state explicitly.
• Data leakage: meta drill-down exposing credentials or internal hostnames to a broader audience than intended.
• CSP breakage: inlined styles suppressed in prod, producing an unstyled grid that looks broken and gets ignored during an incident.
• Payload blowout: a check with a very large record list drives modal width and render time; enforce a cap in CheckIntegration.
• Re-run storm: multiple operators hitting remediation simultaneously on a shared screen.

Ramp-up Low for anyone fluent in Filament — a developer can have it on a panel in an afternoon. The real ramp-up is the CheckIntegration layer and the meta-exposure policy, which require understanding what each health check actually puts in its result. Plan roughly a day of engineering plus a security/policy review before it faces operators.