Horizon Extended Dashboard Laravel Package

Getting Started

1. composer require vincentbean/horizon-extended-dashboard — the package layers on top of Laravel Horizon, so Horizon itself must already be installed, configured against Redis, and running (php artisan horizon).
2. Publish what's needed before first use: check php artisan vendor:publish for the package's provider tags (config and, depending on setup, compiled assets). Without published assets the extra panels/columns won't render.
3. Log into /horizon and open any queue — pending, completed, or failed. The extended view is the place to look first: instead of the stock "job class + tags + attempts" summary, you get the decoded queue item, which is where the package earns its keep.
4. First real use case: triage a failed job without attaching a debugger. Find the job by tag, read the payload, confirm which model ID / arguments it was actually dispatched with, then retry.

Implementation Patterns

• Incident debugging loop. Use the payload view to answer "what arguments did this job actually get?" — the common failure mode where a job was dispatched with a stale model or a missing constructor argument is invisible in stock Horizon but obvious in a decoded payload.
• Queued mail. As of 1.2.2, a queue item backed by Illuminate\Mail\SendQueuedMailable resolves to the underlying Mailable class rather than the framework wrapper. This matters for mail-heavy apps: you can now scan the queue and see App\Mail\OrderShipped entries instead of a wall of identical framework class names. Practical consequence — tagging and filtering by mailable class now works the way you'd expect, so make sure your queue naming/filtering strategy accounts for it rather than grouping everything under the wrapper.
• Pair with tags. The payload view is far more useful when jobs implement tags(); do that consistently and the extended dashboard becomes a searchable index of business events rather than a list of class names.
• Keep it in the deploy pipeline. If you publish assets into your own repo, add the publish step to your build so dashboard code doesn't drift from the installed package version.
• Extension point. Any custom job wrapper (your own mailable dispatcher, a third-party queueable envelope) will render as its wrapper class. Treat the unwrapping logic as the thing to extend upstream — submit a PR for the wrapper class rather than forking.

Gotchas and Tips

• Payloads are not small. Decoding a job that carries a fully serialized Eloquent model can produce a large blob. Expect the detail view to be slower than the list view on jobs with fat payloads; don't leave it open on a production dashboard during a backlog flush.
• Truncation surprises. Horizon's trim settings (horizon.trim.recent, horizon.trim.pending, etc.) and Redis memory limits may mean the item you're inspecting is incomplete or gone. If fields look empty, check trim config before assuming a package bug.
• This is a read-only debugging surface over production data. Serialized payloads routinely contain model attributes, IDs, email addresses, and occasionally API tokens passed as constructor args. Re-verify your Horizon::auth gate and don't widen access just because the dashboard is now more informative.
• Stale published assets after upgrade. The 1.2.2 change is a rendering-logic change in how queue items are resolved. If you published the Vue/JS assets, re-publish with --force and rebuild; otherwise you'll install the PHP side and see no difference in the UI.
• Pin the minor version. 1.2.x patch releases have altered item-resolution behaviour; if your team's runbooks depend on exact payload output, pin to ^1.2.2 and upgrade deliberately.
• Debugging a missing panel: confirm Horizon's own service provider is registered and its assets are published first — this package degrades to nothing visible when Horizon itself is misconfigured, which reads like a package failure.