- How do I install mateusjunges/laravel-trackable-jobs in a Laravel app?
- Run composer require mateusjunges/laravel-trackable-jobs, then publish the package config and migration and run php artisan migrate. The service provider is auto-discovered, so there is no manual registration step. After that, add the Trackable trait to the jobs you want to instrument or enable global tracking in trackable-jobs.php. A proof of concept typically takes a mid-level Laravel engineer less than a day.
- Which Laravel and PHP versions does this package support?
- The technical evaluation assumes a conventional Laravel 9 to 11 application on PHP 8.1 or newer. Always check the composer.json constraints in the repository before upgrading a major Laravel version. Because it relies on standard queue lifecycle events and an auto-discovered provider, it installs like any other Laravel package.
- Does laravel-trackable-jobs replace my queue driver?
- No. It hooks into Laravel's queue lifecycle events instead of replacing the driver, so it layers onto existing Redis, SQS or database queue setups. Your dispatch sites and job payload shape stay unchanged. The package simply persists state transitions into a tracked_jobs table.
- Can I track all jobs globally instead of adding a trait to every job?
- Yes. There are two adoption modes: opt in per job with the Trackable trait, or enable tracking for all jobs through the published trackable-jobs.php config. That makes a phased rollout practical, so you can instrument business-critical jobs first. Status is then readable by querying the tracked_jobs table from your own application code.
- Will job tracking add too many database writes at high queue volume?
- Write amplification is the main risk: each tracked job produces several inserts and updates as it moves from queued to running to finished or failed, plus per-attempt records. At high throughput that turns tracked_jobs into a write hotspot on the primary database, so load-test against peak job volume before broad enablement. Tracking only critical queues is the usual mitigation.
- What happens to my job if the tracking database write fails?
- This behavior is not clearly documented, and it is unverified whether a failed tracking write aborts, delays or silently ignores the underlying job. That distinction decides whether the package is a safety net or a new failure domain, so test it deliberately, for example by removing write access to tracked_jobs on one worker. Also confirm your workers can reach the relational database at all, since network-isolated workers cannot record state.
- Does it track job batches, chains, retries and attempts?
- Retries and attempts are represented through per-attempt rows, which helps you spot flaky jobs. Coverage of batches, chains, the sync driver, queued closures and Horizon supervisors is not fully documented, so verify the specific cases you depend on with a short test. Batch-level and supervisor-level semantics are the areas most worth checking before rollout.
- Is this a replacement for Horizon or Telescope, and does it include a dashboard?
- It is a persistence layer rather than an observability product, so there is no UI, alerting or metrics emission. Horizon and Telescope stay useful for live inspection, while this package gives you durable, queryable job history. Any dashboard, SLA reporting or paging has to be built on top of the tracked_jobs table yourself.
- What happens to jobs stuck in running if a worker is killed?
- If a worker dies mid-job through SIGKILL, OOM or a deploy rollout, the row stays in a running state and nothing reconciles it automatically. Dashboards will silently misreport those jobs unless you build a staleness sweep that flags or prunes old running rows. Schedule that sweep alongside your other housekeeping commands.
- How should I handle pruning and payload data in tracked_jobs?
- Stored records can include serialized job payloads and exception traces, which creates a retention and potentially GDPR review surface for security and legal. The package is a persistence layer, so plan your own pruning strategy, typically a scheduled delete of rows older than a set age. Confirm with your team which payload data is acceptable to keep in a queryable table.