- How do I install twigger/laravel-job-status in a Laravel app?
- Install it with Composer via composer require twigger/laravel-job-status, then publish the package assets and run the migration to create the job status table. Add the package trait to the job classes you want tracked, and optionally publish the config file if you need to customise broadcasting or table settings. The whole setup is one trait, one model, and a small config file, so it is usually under an hour of work plus testing.
- Which Laravel and PHP versions does twigger/laravel-job-status support?
- The package was last released in July 2023 and has not been validated against Laravel 11 or 12 or the current PHP minors, so treat the version constraints in composer.json as the only authoritative statement. Pin an explicit version rather than using a floating constraint, and run composer why-not against your target Laravel version before planning a framework upgrade. A short smoke test on your actual Laravel and queue driver combination is the only reliable way to confirm compatibility.
- How do I track a specific job's status and progress?
- You opt individual jobs in by adding the package trait to the job class, which is how the package knows which dispatched jobs should get a persisted status row. Once tracked, the package records transitions through Laravel's queue events, and you can query the Eloquent model to read the current state or update it with your own progress information. Because tracking is opt-in per job, you can roll it out queue by queue instead of enabling it globally.
- Is twigger/laravel-job-status a replacement for Laravel Horizon?
- No. Horizon is an operator-facing dashboard for supervising queue workers, while this package provides application-level, queryable, model-associated status that you can surface in your own product UI. If you already run Horizon, the two are complementary and can coexist. Use this package when you need to tell an end user that their export is queued, running, ready, or failed, not when you need to inspect worker throughput.
- Does it work with Redis, database, and SQS queue drivers?
- The package hooks Laravel's generic queue lifecycle events such as JobQueued, JobProcessing, JobProcessed, and JobFailed rather than a driver-specific API, so in principle it is driver-agnostic across database, Redis, and SQS. The important caveat is that it only sees jobs dispatched through Laravel's dispatcher, so jobs produced by external systems or other languages sharing the queue will not be tracked. Verify with a smoke test on your actual driver rather than assuming.
- How are retries, batches, and chains represented in the status table?
- The design persists one row per tracked job, and a retry re-fires the queue events so the same row is updated to reflect the latest attempt rather than creating a separate history row per try. Batch and chain semantics are not clearly documented in the package, so validate them in a spike before relying on them for user-facing messaging. If you need per-attempt audit history, plan to add your own listener and table rather than expecting it out of the box.
- What happens if a queue worker is killed mid-job — will the status get stuck?
- Status updates depend on Laravel firing terminal events, so a worker that dies from an OOM kill or kill -9 without firing JobProcessed or JobFailed can leave a row stuck in a running state. There is no documented reaper that reconciles these orphaned rows. Plan a scheduled sweep that marks rows as stale after a timeout longer than your longest expected job runtime.
- Does it support broadcasting status updates in real time, and can a broadcast failure break the job?
- Yes, broadcasting is optional and configurable, and the package emits broadcast events on status transitions so a front end can subscribe through Reverb, Pusher, or Soketi. Because broadcasting happens on the worker path, verify in a smoke test that a failing broadcaster can never bubble up and fail the underlying job. If you are unsure, queue the broadcast or wrap it defensively before enabling it in production.
- Will it scale on high-volume queues, and how do I prune old status records?
- Every status transition is a database write on the worker path, which is fine at hundreds of jobs per hour but needs sizing and possibly a separate connection at hundreds of jobs per second. There is no documented retention or pruning policy shipped with the package, so you should write your own scheduled command that deletes terminal rows older than your retention window. Roll coverage out job by job with a per-queue write-volume budget instead of enabling the trait everywhere in one pull request.
- Is twigger/laravel-job-status actively maintained and safe to use in production?
- It has a single maintainer, very few stars and dependents, and no release since July 2023, so realistically it is untested against current Laravel and PHP versions. Treat it as a vendored dependency with a known upgrade tax rather than a supported platform component: pin the version, add a review step to your Laravel upgrade checklist, and be ready to fork. The MIT licence and small surface area keep the fork cost low, which makes it a reasonable fit for internal product-facing job visibility at modest queue volumes.