Product Decisions This Supports
- Admin/ops surface in-product: Power a support-facing or internal admin panel that shows live queue depth, consumer counts, message rates, unacked messages, and connection/channel counts per tenant or environment — without asking ops to screenshot the RabbitMQ UI. Decision it informs: whether queue visibility belongs in our product or in a separate ops tool.
- Health checks and alerting hooks: Read broker/node health and queue metrics from application code to drive readiness probes, threshold alerts (queue depth, dead-letter growth, no-consumer conditions), and status pages. Decision it informs: what "healthy" means for our async workloads and which failures page a human.
- Capacity planning and infra spend: Node-level and queue-level metrics feed right-sizing decisions — add brokers vs. tune prefetch vs. split queues. Decision it informs: infra budget and timing of scaling work.
- Build vs. buy for messaging plumbing: The RabbitMQ Management API is a documented REST/JSON surface; this package is a thin PHP client over it. Decision it informs: adopt this, write ~200 lines of Guzzle/Laravel
Http calls ourselves, or buy managed observability (Datadog, CloudAMQP dashboards, Prometheus + rabbitmq_exporter).
- Roadmap triage for observability debt: If the team keeps improvising scripts to answer "is the queue backed up?", that's a recurring cost signal that justifies a small, owned internal tool.
- Use cases: internal support dashboard, tenant-level queue introspection, pre-deploy smoke checks, incident triage runbooks, SLA reporting on async job latency.
When to Consider This Package
Consider it when:
- You self-host RabbitMQ and your application is PHP/Laravel, and you need programmatic access to broker stats from app code (not just a human opening the management UI).
- You need a fast prototype — an internal dashboard or health check — measured in days, not a platform investment.
- You want MIT-licensed, Composer-installable code that saves the boilerplate of auth, pagination, and endpoint plumbing.
Look elsewhere when:
- You need real metrics infrastructure or alerting — Prometheus (
rabbitmq_exporter or the Prometheus plugin), Datadog, or Grafana is the right layer; this package is a client, not a monitoring system.
- You need guaranteed maintenance, typed interfaces, or vendor support. The signals are thin: 39 stars, 0 dependents, last release December 2020. Assume no PHP 8.1+/Laravel 11 compatibility guarantee and plan to verify or patch.
- You need write/remediation operations (purge, delete queue, policy changes). Confirm endpoint coverage before designing a runbook around it — the value here is predominantly read-side.
- You're on a managed broker whose dashboard already answers the question, or your team has no PHP service owning the broker (a sidecar/exporter in any language is a better fit).
- The whole requirement is one or two GET calls — a direct HTTP client is cheaper than a dependency.
Gate to apply: treat adoption as a spike, wrap it behind an internal interface (e.g., QueueMetricsRepository), and keep the swap cost to an afternoon.
How to Pitch It (Stakeholders)
To executives: This is a low-cost, low-risk enabler for operational visibility. It lets us surface RabbitMQ health — backlog, consumers, throughput — inside tooling we already own, with no new infrastructure and no vendor spend. The strategic question it answers is whether async reliability is visible enough to protect SLAs; today it's mostly tribal knowledge. The main risk is that the library is a small, unmaintained open-source project, which we contain by wrapping it, pinning the version, and being willing to replace it with our own thin client.
To engineering: MIT-licensed, Composer-installable client over the RabbitMQ Management HTTP API. It removes a day or two of HTTP/auth/pagination boilerplate for read-side metrics. It is not a monitoring platform and is not maintained actively — so no domain code touches it directly; it sits behind our own interface, with tests, and we own the failure modes. If we outgrow it, the replacement is small.
Recommendation: Fund a 1–2 day time-boxed spike against a non-production broker to prove one concrete outcome (an internal queue-health view or a health-check endpoint). At the end, decide between (a) keep and wrap, (b) build in-house on our HTTP client, or (c) route the need to Prometheus/Datadog and drop the in-app requirement. Don't adopt it as a critical-path dependency without that gate.