Flarum Horizon Laravel Package

Product Decisions This Supports

• Build vs. buy for operational visibility. The extension puts queue and Redis health in front of admins instead of requiring a bespoke internal dashboard, a paid APM seat, or SSH access to the host. That is a real "don't build it" argument for small teams.
• Roadmap: admin-facing ops tooling. Whether "operational visibility" is a workstream worth funding, or whether we deliberately punt to external monitoring (Datadog/Sentry/Horizon's own UI) and accept that non-engineers can't self-serve.
• Infrastructure standardization. The 0.4.3 addition of Redis memory eviction policy in the admin widget turns a silent failure mode ("why did our cache/queue keys vanish?") into something a non-engineer can see and escalate. That directly informs whether we mandate a Redis policy (noeviction vs. allkeys-lru) across environments.
• Use cases served: self-hosted Flarum communities on Redis-backed queues; small ops teams without a dedicated SRE; support staff answering "is the queue backed up?" and "is Redis under memory pressure?" without shell access.
• Maintenance-health input for dependency review. 0.4.3 is a patch release: a correctness fix (max memory was always rendering as "auto", i.e. the widget was quietly lying) plus a small widget enhancement. No breaking changes and no deprecations — evidence of a maintainer polishing the ops surface rather than expanding scope.

When to Consider This Package

Consider adopting when:

• You run Flarum on Laravel with Redis-backed queues, and Horizon is already (or about to be) part of your stack.
• Your admin/ops surface is thin and non-engineers need read-only health signals inside the panel.
• You want visibility without standing up a second monitoring product, and can pin versions (0.4.x) and absorb occasional 0.x churn.
• You care specifically about Redis memory pressure and eviction behavior, which this release makes legible.

Look elsewhere when:

• You're not on Flarum or don't use Redis queues — the package has no standalone value.
• You need alerting, paging, retention, or SLO reporting. This is a display layer; it will not wake anyone up. Keep native Horizon/Redis tooling or an APM as the system of record.
• You require vendor support, SLAs, or audit-grade telemetry — this is a community 0.x extension.
• You can't accept third-party extension risk in the admin panel.

On this release specifically: 0.4.3 is routine patch-level maintenance. It is a positive maintenance signal and mildly strengthens the "memory/eviction visibility" use case, but it should not, on its own, trigger an adoption decision or a re-architecture. Treat it as confirmation the package is alive, not as a new capability milestone.

How to Pitch It (Stakeholders)

Executives: A small, actively maintained add-on that shows queue and Redis health to the people who actually operate our community — no new monitoring contract, no elevated server access for admins. The latest patch fixes a misleading memory reading (the widget previously always reported "auto") and surfaces Redis eviction policy, the setting most likely to explain a sudden, mysterious loss of cached data. Low cost, low risk, clear operational upside.

Engineering: Flarum extension wrapping Laravel Horizon. Integration cost is near zero if Horizon + Redis are already in place; this release implies no migrations or config changes. Two changes: a display bugfix for max-memory reporting, and read-only exposure of the eviction policy in the Redis admin widget. Pin to 0.4.x; 0.x versioning means UI-level churn is possible between minors.

Risk framing: Treat it as convenience tooling, not a system of record. It observes; it does not alert. Keep Horizon and Redis-native metrics as the escalation path, and don't let the widget's presence substitute for actual monitoring coverage.