Messenger Monitor Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for internal ops tooling. A read-only Messenger queue/transport dashboard is a classic "would be nice, nobody wants to own it" internal tool. This package answers the question "do we spend two sprints building an admin screen, or adopt a bundle and spend those sprints on the roadmap?" — with a decision that costs days instead of weeks.
• Whether async workloads are a first-class product surface. If order confirmation, webhook delivery, or email dispatch runs through Messenger, queue depth and failure rates are product health metrics, not infrastructure trivia. This package is the cheap way to make that visible before committing to a real observability budget.
• Incident-response and support-tier decisions. Seeing failed messages and transport backlogs lets support answer "did my job run?" without escalating to engineering — a concrete input to whether you need a paid support tier or an on-call rotation.
• SLO and alerting thresholds. Baseline failure counts and queue depth are prerequisites for picking SLOs on background processing. You can't set a "99% of messages processed within 60s" target without first measuring.
• Roadmap sequencing for platform work. If the dashboard surfaces chronic retries or a stalled transport, that's evidence to prioritize worker scaling, retry policy, or transport migration over new features.
• Buy-vs-build for the underlying queue transport. Monitoring gaps differ by transport (AMQP vs. Doctrine vs. Redis); the package's per-transport view informs whether consolidating transports is worth the migration cost.

When to Consider This Package

Adopt when most of these are true:

• You're on Symfony, not Laravel. The package is a Symfony bundle targeting Symfony Messenger. Under Laravel, the equivalent is Horizon (Redis queues), Telescope, or a hosted APM — this bundle will not meet you where you are. If your stack is Laravel, stop here and evaluate Horizon first.
• You use Messenger with one or more transports and have no existing queue visibility (no Sentry breadcrumbs, no Datadog queue metrics, no custom dashboard).
• You need operator-facing visibility, not machine-consumable metrics — this is a UI bundle, not an alerting or time-series backend.
• Your team is small enough that a bundled admin page beats a Grafana/Datadog build-out, and you accept a security-scoped, internal-only surface.
• You can absorb adoption risk: 93 stars, zero dependents, and a single-maintainer-adjacent provenance (SymfonyCasts) indicate an immature ecosystem signal. Pin the version, wrap it behind an access-controlled route, and be prepared to fork.

Look elsewhere when:

• You need durable metrics, alerting, or retention — pair with (or replace by) an APM/observability vendor.
• You need multi-tenant or customer-facing queue status; this is an internal debugging tool, not a product feature.
• You require vendor SLAs or long-term support — MIT with thin adoption means you own the maintenance.
• Your queue volume is high enough that dashboard polling itself has operational cost.

How to Pitch It (Stakeholders)

To executives: We have a visibility gap in background processing — when a job silently fails, nobody finds out until a customer complains. This is an MIT-licensed, drop-in admin view for Symfony Messenger queues that gives us queue depth and failure visibility in roughly a day of integration, versus an estimated 2–3 sprints to build equivalent tooling or a recurring APM line item. It's deliberately scoped as internal diagnostics: low cost, low lock-in, easy to remove. Recommendation: timeboxed pilot on staging and one production environment, with a decision gate on whether it reduces time-to-diagnosis before we consider anything larger.

To engineering: This is a Symfony bundle (not Laravel — no Horizon overlap). It surfaces transport and queue state through a bundled UI, requires no schema changes and no application code changes beyond route registration and access control. Caveats worth naming up front: thin adoption (93 stars, no dependents), so we pin the version, restrict the route to staff, and treat the UI as read-only diagnostics we could replace. If we later need metrics, alerting, or retention, we layer on an observability backend rather than extending this — the bundle tells us whether that spend is justified.

Decision requested: approval for a one-day spike plus a two-week evaluation window, with a go/no-go on reduction in mean time to diagnose failed messages.