I was working on a Laravel project for a client — standard stuff, database queue driver, shared hosting, nothing fancy.
A payment job started failing silently.
No alert. No dashboard. Just a frustrated client asking why invoices weren't being sent.
I opened the failed_jobs table and started reading raw JSON stack traces. Then I ran php artisan queue:work with my eyes glued to the terminal. Then I wrote a quick throwaway script to query the jobs table.
You know the feeling.
The obvious fix is Laravel Horizon — it's a beautiful dashboard and I've used it many times. But Horizon requires Redis. This project was on shared hosting with no Redis. And honestly, for a small project, spinning up Redis just to get queue visibility felt like overkill.
So I spent a few evenings building something lightweight.
What I built
Lightweight Queue Inspector — a debugging dashboard for Laravel apps using the database queue driver.
No Redis. No Horizon. Just your existing jobs and failed_jobs tables.
Here's what it gives you:
- Pending jobs — see everything waiting in the queue, with collapsible payload inspection
- Failed jobs — full exception messages, stack traces, retry or delete individually or in bulk
- Successful jobs — execution time per job (colour coded green/orange/red) and memory usage
- Dashboard stats — pending count, failed count, avg execution time, top failing job
- Filters — filter any page by queue name or job class
- Security warnings — terminal warnings if you forgot to add auth middleware, or if auth is set but no login route exists
How it works under the hood
The package hooks into Laravel's built-in queue events — no extra config, no extra tables beyond one small metrics table:
| Event | What gets recorded |
|---|---|
JobProcessing |
job class, queue name, started_at |
JobProcessed |
execution_time_ms, memory_usage_mb, status = success |
JobFailed |
execution_time_ms, exception message, status = failed |
These events fire automatically when php artisan queue:work processes a job. You get full visibility into what's running, how long it takes, and what's failing — without touching a single line of your application code.
Install in 2 minutes
composer require abinashbhatta/lightweight-queue-inspector
php artisan migrate
Visit /queue-inspector. Done.
The package auto-discovers — no need to register anything in config/app.php.
Always protect it in production:
// config/queue-inspector.php
'middleware' => ['web', 'auth'],
Who is this for?
If you're using Horizon and Redis already — stick with Horizon, it's excellent.
This is for the rest of us:
- Small to medium projects on shared hosting
- Internal tools and admin panels
- Early-stage apps where Redis is overkill
- Anyone who just wants to see what their queues are doing right now
What's coming next
I'm planning to add auto-refresh, email/Slack alerts on job failure, dark mode, and charts showing job trends over time. The full roadmap is on GitHub.
GitHub: https://github.com/abinash889/lightweight-queue-inspector
Packagist: https://packagist.org/packages/abinashbhatta/lightweight-queue-inspector
If you've ever been in that same situation — debugging queues blind at an inconvenient hour — I'd love to know what you think. What would make this more useful for your projects?
Top comments (2)
You seriously can't configure Horizon to work with DB queues. I did not know that!
Yeah, it's a pretty common surprise! Horizon is tightly coupled to Redis — it uses Redis lists as the queue backend and also stores its metrics and job data there, so there's no way to swap it out for the DB driver. It's an intentional design choice since Redis gives Horizon the speed and real-time push it needs.
That's exactly the gap I ran into — lots of projects are on shared hosting or just don't have Redis set up yet, and there was no lightweight option in between "read the raw jobs table" and "spin up Redis + Horizon." Glad this helps clarify it!