Laravel Queue Metrics Laravel Package

Product Decisions This Supports

• Queue observability roadmap: The package supports Laravel queue/job discovery and queue metrics calculation. Use it to decide whether to expose queue inventory, job activity, and metrics internally, in dashboards, or in operational runbooks.
• Build vs. buy: v3.5.1 reinforces the case for using the package instead of custom Redis-backed discovery and TTL cleanup logic. The patch fixes a legacy stale-discovery failure mode and reduces Redis round trips in queue-metrics:calculate.
• Incident response and release safety: Accurate listQueues() / listJobs() output matters during queue incidents, migrations, and rolling deploys. The patch prevents retired queues and job classes from remaining visible forever on installs upgraded from v1.x.
• Migration and upgrade planning: The release is a maintenance patch, not a new product surface. Plan normal rollout, but note that reading discovery now prunes legacy keys, so the storage connection must be writable. Also coordinate rolling deploys: scheduler hosts still on v3.4 will not see entries first seen on v3.5 workers.
• Cost/performance decisions: Reading the discovered job list once per run instead of once per queue removes roughly four Redis round trips per queue after the first. This supports scaling to larger queue inventories without proportional command overhead.
• Operational requirements for Redis topology: The documentation now makes writable discovery storage a requirement. Product and platform decisions should account for this when using read-only replicas or restrictive Redis permissions.

When to Consider This Package

Consider adoption when:

• The product runs Laravel queues on Redis and needs lightweight queue/job discovery and queue metrics without building custom Redis bookkeeping.
• The team wants visibility into active queues and job classes, especially after migrations or legacy upgrades where stale discovery entries could mislead operators.
• The Redis connection used for discovery can be writable, because reading discovery prunes legacy keys and applies TTLs.
• The team can coordinate rolling deploys or tolerate temporary discovery gaps between scheduler hosts on older versions and workers on v3.5.
• The organization prefers a focused Laravel package over a larger APM or queue platform for basic queue observability.

Look elsewhere or add compensating controls when:

• Redis is read-only, replicated without writes on the reader path, or governed by strict write-permission constraints.
• Queues are not Redis-backed, or the product needs cross-broker queue observability.
• The team requires full distributed tracing, alerting, SLA dashboards, or long-term metrics retention beyond what this package provides.
• Mixed-version rolling deploys must have zero discovery inconsistency; either coordinate upgrades or supplement with external monitoring.
• An existing Laravel queue dashboard or APM already covers queue inventory, metrics, and incident workflows.

How to Pitch It (Stakeholders)

For executives: This is a low-risk maintenance release for a Laravel queue observability package. It does not add a new product line, but it removes an operational stale-data problem for installs upgraded from older versions and reduces Redis overhead when calculating queue metrics. The business value is better queue visibility, fewer misleading operational signals, and lower risk during migrations and incident response.

For engineering: Adopt v3.5.1 as a normal patch upgrade. It fixes legacy discovery keys that previously had no TTL, applies the aggregated TTL on first read for those keys, and leaves keys that already have a TTL alone. It also makes queue-metrics:calculate read the discovered job list once per run and tightens RedisMetricsStore::expireIfPersistent() to set a TTL only when a key exists and has none. No API break or deprecation is indicated. The main operational caveats are that discovery reads require a writable Redis connection, and during rolling deploys a scheduler host still on v3.4 will not see entries first seen on v3.5 workers. Pitch it as a low-risk operational hygiene and performance patch, not a feature launch.