PHPackages                             henzeb/event-horizon - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Logging & Monitoring](/categories/logging)
4. /
5. henzeb/event-horizon

ActiveLibrary[Logging & Monitoring](/categories/logging)

henzeb/event-horizon
====================

Enables seamless job monitoring and tag management across multiple Redis connections or databases

v1.0.0(11mo ago)02MITPHPPHP ^8.2CI passing

Since Jun 10Pushed 11mo agoCompare

[ Source](https://github.com/henzeb/event-horizon)[ Packagist](https://packagist.org/packages/henzeb/event-horizon)[ RSS](/packages/henzeb-event-horizon/feed)WikiDiscussions main Synced 1mo ago

READMEChangelog (1)Dependencies (5)Versions (2)Used By (0)

Event Horizon
=============

[](#event-horizon)

[![Tests](https://github.com/henzeb/event-horizon/workflows/tests/badge.svg)](https://github.com/henzeb/event-horizon/actions)[![Latest Stable Version](https://camo.githubusercontent.com/09fae5e4f5073d544f3dd12b7fc906a6e4e705c2b82a77e1e1e664940eeef922/68747470733a2f2f706f7365722e707567782e6f72672f68656e7a65622f6576656e742d686f72697a6f6e2f762f737461626c65)](https://packagist.org/packages/henzeb/event-horizon)[![License](https://camo.githubusercontent.com/b496d575acbd63929de2cb7ea5aba7c172a17277f0551741e1e46781b5be4c8c/68747470733a2f2f706f7365722e707567782e6f72672f68656e7a65622f6576656e742d686f72697a6f6e2f6c6963656e7365)](https://packagist.org/packages/henzeb/event-horizon)

Event Horizon fixes Laravel Horizon's job monitoring when you have multiple Redis connections. It makes sure job tracking data goes to the right place - where the job is actually processed, not where it was pushed from.

The Problem
-----------

[](#the-problem)

Horizon gets confused when you use multiple Redis connections. Here's what happens:

You push a job from connection A, but it gets processed on connection B. Horizon shows the job as "pending" on connection A's dashboard, even though it's actually running on connection B. This makes your dashboards misleading and makes it hard to see what's really happening with your jobs.

This becomes a real headache when you're trying to monitor job performance, debug issues, or just understand what's going on in your application. You end up checking multiple dashboards, seeing conflicting information, and never getting a clear picture of your job processing.

The root cause is that Horizon was built assuming you'd use one Redis connection for everything. When you have multiple connections (which is pretty common in modern apps), its monitoring system doesn't know how to handle jobs that cross connection boundaries.

The Solution
------------

[](#the-solution)

Event Horizon fixes this by tracking jobs where they actually get processed. When you push a job to connection B, all the monitoring data (job status, tags, metrics) gets stored in connection B's Redis instance, not where you pushed it from.

This means your Horizon dashboards show the real picture - jobs appear where they're actually running, making it much easier to monitor what's happening. No more hunting across different dashboards or trying to piece together where your jobs really are.

The package works by extending Horizon's core monitoring classes to be connection-aware. It automatically detects which Redis connection a job is destined for and routes all monitoring data there. You don't need to change any of your existing code - it just works.

Installation
------------

[](#installation)

```
composer require henzeb/event-horizon
```

That's it! Works automatically once installed.

When You Need This
------------------

[](#when-you-need-this)

- **Multiple Redis connections**: Your app uses different Redis instances for different purposes
- **Multi-tenant applications**: Each tenant has their own Redis instance and you want isolated monitoring
- **Microservices**: Different services push jobs to different connections
- **Load balancing**: You're spreading jobs across multiple Redis instances
- **Team separation**: Different teams manage different queue connections and want their own dashboards

Example
-------

[](#example)

```
// Configure different connections for different purposes
config([
    'queue.connections.web' => ['connection' => 'redis_web'],
    'queue.connections.reports' => ['connection' => 'redis_reports'],
    'queue.connections.exports' => ['connection' => 'redis_exports'],
]);

// Jobs show up on the right dashboard where they're processed
Queue::connection('web')->push(new ProcessOrder($order));       // Appears on web dashboard
Queue::connection('reports')->push(new GenerateReport($data));  // Appears on reports dashboard
Queue::connection('exports')->push(new ExportData($params));    // Appears on exports dashboard
```

Before Event Horizon, all these jobs might show up on the wrong dashboards depending on where you pushed them from. After installing it, each job appears exactly where you'd expect - on the dashboard for the connection that's actually processing it.

How It Works
------------

[](#how-it-works)

Event Horizon extends three key parts of Horizon:

- **Job monitoring**: Tracks jobs in the correct Redis instance
- **Tag storage**: Stores job tags where the job is processed
- **Event handling**: Ensures monitoring events go to the right place

The package automatically replaces Horizon's default behavior with connection-aware versions. Everything happens behind the scenes - you don't need to change your existing job code or queue configuration.

Requirements
------------

[](#requirements)

- PHP 8.2+
- Laravel Horizon ^5.0
- All Horizon instances must use the same `horizon.prefix` configuration value

License
-------

[](#license)

MIT License. See [LICENSE.md](LICENSE.md) for details.

###  Health Score

29

—

LowBetter than 59% of packages

Maintenance51

Moderate activity, may be stable

Popularity2

Limited adoption so far

Community6

Small or concentrated contributor base

Maturity49

Maturing project, gaining track record

 Bus Factor1

Top contributor holds 100% of commits — single point of failure

How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window.

**Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores.

**Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement.

**Maturity (30%)** — Project age, version count, PHP version support, and release stability.

###  Release Activity

Cadence

Unknown

Total

1

Last Release

343d ago

### Community

Maintainers

![](https://avatars.githubusercontent.com/u/15928532?v=4)[henzeb](/maintainers/henzeb)[@henzeb](https://github.com/henzeb)

---

Top Contributors

[![henze-housepedia](https://avatars.githubusercontent.com/u/72211615?v=4)](https://github.com/henze-housepedia "henze-housepedia (1 commits)")

---

Tags

laravelmonitoringredisqueuedashboardjobsmulti-tenanthorizonmicroservicesqueue monitoringmulti-connectionjob-trackingredis-connectionshorizon-extension

###  Code Quality

TestsPest

### Embed Badge

![Health badge](/badges/henzeb-event-horizon/health.svg)

```
[![Health](https://phpackages.com/badges/henzeb-event-horizon/health.svg)](https://phpackages.com/packages/henzeb-event-horizon)
```

PHPackages © 2026

[Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)