Filament Health Dashboard Laravel Package

Product Decisions This Supports

• Build vs buy for the ops UI layer. Adopt spatie/laravel-health as the check engine and this package as the presentation/action layer, rather than commissioning a bespoke health dashboard. The scope avoided — page, widget, drill-down modal, JSON viewer, table renderer, action plumbing, notification handling — is typically 1–3 weeks of build plus indefinite upkeep.
• Roadmap sequencing. Turns "improve observability" from an open-ended initiative into a single-sprint, low-risk deliverable, freeing the roadmap slot for the work that actually moves reliability (alert routing, on-call rotation, SLOs) instead of UI plumbing.
• Deployment/ops simplification. The inlined stylesheet removes the php artisan filament:assets publish step from the pipeline. That is a genuine ops decision, not a cosmetic one — it matters for teams with locked-down CI/CD, containers with immutable filesystems, or no frontend build step at deploy.
• Incident response design. The failing-count nav badge, optional auto-refresh, and manual re-run put health where operators already are (the panel) instead of a separate tab. Fewer context switches between "something's wrong" and "here's what's wrong."
• Extensibility budget. Generic Result->meta rendering (scalar inline, nested as JSON, record lists as tables) means new checks ship without frontend work. Teams can add checks in a PR without touching this package or writing per-app view code — a concrete answer to "how expensive is the next check?"
• Support/escalation model. Safe actions with explicit success/failure notifications, authorization, and debounce establish the pattern for "operator fixes it from the dashboard." Supports a decision to invest in self-serve ops tooling rather than paging an engineer for routine remediation.
• Surface placement per audience. Three surfaces (standalone page, widget, <livewire:filament-health-dashboard /> embed) let you decide where health lives by audience: full page for ops, widget on the main dashboard, embedded where it fits an internal or customer-facing context.
• CheckIntegration as the extension point. Decide per check whether it earns a rich table or a remediation button. This is the line item for "how much custom ops UX do we actually need," and it keeps that cost opt-in rather than baked into the core.

When to Consider This Package

Adopt when:

• You are already on Filament v4 and already using (or committed to) spatie/laravel-health. This package is an adapter; it adds value only on top of both.
• Your operators live in the admin panel daily and health is currently a /health JSON endpoint nobody watches.
• You want a few named remediation actions ("clear cache," "retry queue") surfaced next to the failing check, with honest success/failure feedback.
• You want it cheap and reversible: one composer dependency, no SaaS contract, no new infra, removable in a single revert.
• Your deploy process is constrained (no asset publishing, no external CDN), where the self-contained styling is a real differentiator.

Look elsewhere when:

• You are on Filament v3 or not on Filament at all — the package has no value outside a v4 panel. Use the spatie/laravel-health JSON endpoint with an external uptime monitor instead.
• You need real monitoring infrastructure: alert routing, history/retention, trend analysis, multi-channel escalation, SLA reporting. This is a dashboard, not a monitoring system. Pair it with one; don't substitute it.
• You need vendor support, LTS, or compliance attestation. v0.1.0 is pre-1.0 open source with no SLA and no semver stability guarantee.
• Your org cannot absorb pre-1.0 API churn. Mitigation is real but manual: pin the exact version, watch release notes, budget a fork/vendor path if the maintainer goes quiet.
• You need multi-tenant or per-team scoping of which checks are visible to whom. Not stated in the release; validate before assuming it exists.

Before adopting at 0.1.0, verify: test coverage and CI status, maintainer activity and issue responsiveness, the spatie/laravel-health version constraint (a tight pin is good; an unbounded one is a risk), and — most importantly — that the re-run action's authorization hook maps cleanly onto your existing policies. "Safe action" means it reports failures honestly; it does not mean it is harmless.

How to Pitch It (Stakeholders)

To executives: One Composer dependency, no new SaaS spend, no new infrastructure. It takes health checks we already run and puts them in the panel our operators already have open, with a badge that tells them when something is failing and buttons that fix the common cases. The win is shorter time-from-detection-to-recovery for the team that already owns the admin panel. The risk is bounded by architecture: it is a presentation layer over a dependency we would keep regardless, so removal is a one-line revert. The honest caveat: it is v0.1.0 open source with no vendor SLA — treat it as an internal operator tool, not as the foundation of a customer-facing uptime commitment.

To engineering: Thin adapter over Filament v4 and spatie/laravel-health, no asset pipeline changes, no new build step, no lock-in beyond the two dependencies. Extension is via CheckIntegration (rich tables, remediation actions) so custom behavior stays opt-in per check. Three things to review before merge: pin the exact version given pre-1.0 semver; keep the native spatie/laravel-health JSON endpoint as a fallback so the dashboard is not a single point of failure for monitoring; and confirm the re-run action's authorization maps to our policies, since it does execute remediation code paths despite being labelled "safe."