Filament Horizon Laravel Package

Product Decisions This Supports

• Build vs. buy for internal ops tooling: Filament Horizon is a thin, opinionated UI layer over Laravel Horizon. It lets a team ship a first-party queue-ops console inside an existing Filament admin panel instead of scheduling custom dashboard work or paying for a separate observability product. The decision it unlocks is "do we build a monitoring surface at all, or do we adopt a composable one?"
• Internal tooling roadmap sequencing: Helps decide whether queue visibility ships as a standalone internal app, a tab in the existing admin, or a later-phase observability investment. Because it attaches to a Filament panel, it reprioritizes "admin panel consolidation" work ahead of "custom ops dashboard" work.
• Platform standardization: If the org already runs Filament for back-office tooling, adopting this reinforces a single admin surface and a single auth/permission model rather than adding another tool with its own access control. That is a consolidation decision, not just a feature decision.
• Support and on-call product decisions: Exposing failed jobs, retries, and queue throughput to non-engineers (support leads, ops managers) changes who can act on incidents. That shapes decisions about escalation paths, SLA tooling, and whether support staff get write access to retry jobs.
• Feature scoping for customer-facing vs. internal surfaces: Clarifies scope boundaries early — this is an operator-facing capability, so it should not be pitched as a customer-facing reliability feature. It informs what goes on the internal roadmap versus the public one.
• Buy-vs-build for observability vendors: A credible baseline for "good enough" queue visibility. Useful as a comparison point when evaluating hosted monitoring tools, and as evidence for whether the existing stack already covers the need.

When to Consider This Package

Consider adoption when most of the following hold:

• The application already uses Laravel Horizon on Redis-backed queues, and the team is comfortable with Horizon's underlying data model.
• The application already runs Filament (v3-era panels), and there is an established admin panel where ops pages logically belong.
• The primary audience is internal — engineers, support, operations — and the value is faster incident triage rather than a new customer promise.
• The team wants low-effort, low-maintenance visibility and is willing to accept a UI wrapper rather than a bespoke dashboard with custom metrics, alerting, and retention.
• Access control can be expressed through existing Filament panel authorization (policies, gates, role checks) rather than a separate permission system.
• There is appetite to pin and upgrade deliberately — this is an initial v1.0.0 release with no track record.

Look elsewhere when:

• Queues are not Redis/Horizon (SQS, database, RabbitMQ) — Horizon itself is the wrong foundation.
• The team does not use Filament and has no intention of adopting it; adding Filament solely to host this package is a large, unrelated commitment.
• Requirements include alerting, long-term metrics retention, SLO tracking, or cross-service tracing — this is a UI over Horizon's snapshot data, not an observability platform.
• The audience is external customers or uptime-sensitive stakeholders who need contractual reliability reporting.
• The organization has compliance or vendor-review requirements that a young, single-maintainer-ecosystem package cannot yet satisfy.
• You need guarantees on backwards compatibility and long-term support; v1.0.0 with no release history provides none.

Adoption should be treated as a trial, not a commitment: integrate behind existing panel authorization, keep Horizon as the source of truth so removal is trivial, and revisit after a few upgrade cycles.

How to Pitch It (Stakeholders)

For executives (one paragraph): Filament Horizon adds queue monitoring screens to the admin panel we already run, so the team can see failed and delayed jobs where they already work instead of in a separate tool. It is a small, reversible addition that improves how fast we detect and clear stuck background work — the kind of issue that shows up as slow pages or missing emails. Because it sits on top of Laravel Horizon, which we already depend on, the cost is low and the exit path is clean. It is not a customer-facing feature, not a replacement for our monitoring vendor, and not something to announce externally; it is an internal efficiency play we should trial and review.

For engineering leads: This is a Filament page and widget set over Horizon's existing APIs — no new infrastructure, no new datastore, no new auth model. It inherits panel authorization, so access is governed by policies we already write. Horizon remains the source of truth, so the package is removable without data loss. Risks are maturity and version coupling: v1.0.0, young ecosystem, and it tracks Filament's release cadence, so pin the version, keep the integration behind a feature flag or panel, and budget a small upgrade check each Filament bump. Recommend a scoped trial on one internal panel with read-only access first, then widen to retry actions once we have confidence.

For the product team: Treat this as internal tooling, not roadmap surface area. It reduces time-to-diagnose for background job failures and can shift retry capability from engineers to support — a workflow change worth agreeing on explicitly, including who is allowed to retry or delete jobs. Success looks like shorter incident triage and fewer escalations to engineering, not new user-facing capability.