Oc Horizon Plugin Laravel Package

Product Decisions This Supports

• Build vs. buy for queue observability. The plugin answers "do we build our own queue dashboard, or adopt Horizon's?" For an October CMS product already on Redis, the answer is nearly always adopt — this is a thin adapter over a first-party Laravel package, so you inherit supervisor orchestration, retry/delete tooling, and throughput graphs at roughly zero engineering spend. The alternative (internal admin screens for failed jobs) is a multi-sprint distraction from roadmap work.
• Support-ticket and incident triage decisions. Failed-job inspection with one-click retry/delete turns "a customer says their invoice email never arrived" from an engineering investigation into a support-desk action. That is a headcount decision: does support get the tooling, or does every failed job route through engineering?
• Roadmap sequencing for operational maturity. Adopting this effectively commits the product to Redis-backed queues. That is a platform commitment, not a UI decision — it gates later work on autoscaling workers, dedicated per-workload queues, and alerting on waits thresholds. Put it before, not after, any roadmap item that assumes reliable async processing (notifications, exports, webhooks, media processing, billing).
• Prioritization input: per-queue wait times. Once jobs are routed to dedicated queues, Horizon's per-queue metrics give you evidence for where to invest — if mail backs up at 300s while default is idle, that's a product scaling problem with a number attached, not an anecdote. This is the strongest ongoing PM value: it converts infrastructure complaints into ranked backlog items.
• Capacity and cost decisions. Supervisor maxProcesses, balance: auto, and maxTime/maxJobs settings are direct levers on infrastructure spend and worker stability. A PM should own the acceptance criteria here ("p95 wait under 60s at 3× current volume") rather than leaving it to whoever last touched the config.
• Release-risk decision on the 3.4.0 upgrade. The published notes contain only an auto-generated compare link — no change description. That's a go/no-go decision for production: pin 3.3.*, obtain the actual diff, and classify it as patch-equivalent or behavioral before upgrading. A minor bump can silently change PHP/October/Laravel floors or the published config/horizon.php stub that overwrites tuned supervisors.
• Scope boundary: this is CMS-specific, not a general capability. Non-October Laravel services get Horizon directly, no plugin needed. If the estate is heading toward several non-October services, buying a CMS adapter doesn't compound — argue for standardizing on October or on plain Laravel and consolidating, rather than maintaining a per-CMS integration story.

When to Consider This Package

Consider it when all of these are true:

• The product runs October CMS 3.x and queues are (or will be) on the Redis connection. Horizon supervises Redis only — installing this against database or sync yields an empty dashboard and no value.
• You have, or will fund, an external process supervisor (systemd/supervisord/container sidecar) for php artisan horizon. The plugin cannot provide this; without it the dashboard shows a dashboard, not running workers.
• A named owner exists for config/horizon.php — supervisors, balancing, tries/timeout/memory, and the ordering rule job timeout < supervisor timeout < retry_after. Misconfiguration here produces duplicate job executions, which look like product bugs.
• Failed-job visibility is currently a support cost or an engineering interruption you can quantify. That's the ROI denominator.

Look elsewhere — or treat as a spike, not a dependency — when:

• The repo is archived. This is the dominant finding. An archived, 8-star repository with an undisclosed changelog and a single-maintainer bus factor is not a long-term dependency; it's a candidate for a timeboxed evaluation and, if adopted, for vendoring or a maintained fork with a named internal owner. Plan the exit before you plan the rollout.
• You are not on October CMS. Use Laravel Horizon directly.
• You need granular, per-tenant or per-role dashboard access. Extension points beyond configuration are thin. Authorization is a gate you write yourself against October's backend permission model — verify explicitly that the dashboard is unreachable logged out and unreachable by a non-privileged backend user. This surface includes retry, delete, purge, and supervisor control; a loose binding is a real incident, not a cosmetic issue.
• You need vendor SLA or a documented upgrade path. There isn't a CHANGELOG beyond GitHub's auto-generated one; ask what actually changed between 3.3.0 and 3.4.0 because the release notes won't tell you. Also confirm whether the plugin pins laravel/horizon or inherits the host app's version — if it pins transitively, it can conflict with a Horizon version required elsewhere and surface as an app-wide boot failure rather than a dashboard break.
• Queues aren't Redis yet and there's no funding to move them. The migration to Redis is the actual project; the plugin is the last step.

How to Pitch It (Stakeholders)

To executives — one paragraph: "We're running background work (emails, exports, integrations) on October CMS. Today we can't see whether that work is succeeding, how far behind it is, or what failed — so incidents are discovered by customers and diagnosed by engineers. This package plugs Laravel Horizon's monitoring dashboard into our existing CMS backend: queue depth, throughput, wait times, and a failed-job list with retry. It's an adapter over a first-party Laravel component, so the adoption cost is low — Composer install, a Redis prerequisite we likely already meet, and a dashboard. The caveat is maintenance, not capability: the upstream repo is archived and its latest release shipped with no changelog. My recommendation is a two-week evaluation on staging to prove the value, then a deliberate decision on whether to adopt with an internal owner and a planned fork, or stay with manual queue checks. I'm not recommending we take it on as an unowned dependency."

To engineering — the framing they need:

• What we're buying: Horizon's dashboard, supervisor config, and failed-job tooling inside the October backend — removing hand-wiring work, not adding a system. Nothing new to operate beyond the horizon process itself.
• What we're committing to: Redis queues, a supervised horizon process in production, horizon:terminate in the deploy sequence (not queue:restart), horizon:snapshot on a five-minute schedule or the graphs stay empty, and an authorization gate bound to October's backend permissions.
• What we're not asking you to own blind: an unreviewed 3.4.0. Pin 3.3.*, diff the tags, check whether the published config stub changed (publish to a scratch path and merge by hand — --force will overwrite tuned supervisors), and re-publish Horizon's JS/CSS assets after upgrading or the dashboard 404s its bundle.
• Known sharp edges worth a runbook entry: blank dashboard almost always means Redis is unreachable or APP_ENV doesn't exactly match an environments key — check redis-cli ping and horizon:status before touching the plugin. Run php artisan october:migrate after Horizon upgrades; failed_jobs schema changes surface as exceptions on the first failure after an update.
• Definition of done for the spike: a throwaway job traverses Pending → Processing → Completed; a deliberately failed job appears in Failed with a working retry; the dashboard is verified inaccessible logged out and as a non-privileged backend user; a staging deploy exercises horizon:terminate cleanly.

The decision being requested: approve a timeboxed staging evaluation and name an internal owner for the configuration and upgrade path. If the evaluation lands, adopt with that owner and a pinned version; if the repo's maintenance posture looks worse than it does today, we revert to manual queue checks and revisit with a vendored fork or a build decision — the migration is additive and reversible, so the cost of finding out is two weeks, not a re-platforming.