Messenger Monitor Bundle Laravel Package

Product Decisions This Supports

• Framing the observability gap, not the package choice. This bundle answers a real product question — "do we know what's sitting in our queues and whether transports are healthy?" — but at 14 stars, 0 dependents, and archived status, it informs requirements, not procurement.
• Build vs. buy vs. fork. The package's scope is small and legible (transport introspection, queue depth, failed-message visibility, a simple status view). That gives us a credible build estimate: a spike-sized effort, not a roadmap item. The answer here is "harvest the pattern, own the tool."
• Feature definition for an internal queue dashboard. Use it as a table-stakes checklist: per-transport status, queue depth, failure counts, message lifecycle visibility. Decide deliberately what we don't need (e.g., per-message tracing) so we don't gold-plate.
• Roadmap input on framework strategy. This is a Symfony bundle, not a Laravel package — a material correction to the framing of this evaluation. If we are Laravel-first, this package is out of scope and the relevant comparison set is Horizon (Redis), queue:monitor, or a thin custom health endpoint for non-Redis transports (SQS, database, Beanstalkd) where Horizon doesn't reach.
• Risk decisions. Archived + zero dependents = no security patching, no framework-version guarantees, no upgrade path. That is a hard "no" for anything on the critical path, and it should be recorded so we don't re-litigate it next quarter.
• Opportunity signal. The high opportunity score combined with an abandoned implementation suggests undersupply in "queue visibility" tooling — worth validating whether our own pain here is shared enough to justify building something reusable rather than app-specific.

When to Consider This Package

Adopt only under a narrow set of conditions:

• We run a Symfony application on symfony/messenger, the need is read-only informational visibility, and we are willing to vendor or fork an unmaintained MIT codebase.
• We need a fast internal proof-of-concept and accept that we own the maintenance burden immediately.

Look elsewhere (or build) when:

• We are on Laravel — the package is not applicable, and adopting it would mean dragging Symfony bundle conventions into a Laravel codebase. Non-starter.
• We need alerting, SLOs, or historical metrics, not a status page. Send telemetry to OpenTelemetry/Prometheus and dashboard in Grafana; that scales and integrates with existing on-call.
• We need a maintained dependency with an upgrade path, security response, or vendor accountability — required for compliance or production-critical paths.
• We need multi-tenant, high-volume, or cross-service queue visibility; a bundle UI scoped to one app won't get there.

Preferred alternatives to evaluate: Laravel Horizon (Redis), actively maintained queue-monitor packages, Symfony's built-in Messenger data collector/profiler for dev, and OTel/Prometheus + Grafana for production.

How to Pitch It (Stakeholders)

To executives: "This is a design reference, not a dependency recommendation. It confirms that queue and transport visibility is an underserved need — and it demonstrates the minimum viable feature set. It is archived, has essentially no adoption, and receives no security updates, so we should not build on it. Recommendation: fund a short spike to define our own queue-health requirements and cover them with tooling we control."

To engineering: "If we're Symfony-based, we can lift the introspection approach — it's MIT, small surface area — into our internal admin panel in a spike rather than taking on an abandoned dependency. If we're Laravel-based, the equivalent is Horizon for Redis and a thin custom health endpoint plus metrics export for everything else. Either way, we own the code and the upgrade path."

The ask: approve a time-boxed spike to (1) enumerate queue-observability requirements — depth, failures, lag, alerting — and (2) choose between extending existing tooling and building a minimal internal dashboard. Record the decision that archived, zero-dependent packages are reference material only, so this doesn't resurface.