Laravel Trackable Jobs Laravel Package

Product Decisions This Supports

• Whether to ship async/long-running work with a visible status. Exports, bulk imports, report generation, media transcoding, webhook/PDF fan-out — the recurring blocker is "we can't show the user anything until it's done." A job-tracking record (queued → running → finished/failed, timestamps, attempts, duration, exception) is the minimum viable substrate for progress UI, "your export is ready" notifications, and retry buttons. This package makes that a table plus a trait rather than a bespoke subsystem.
• Build vs. buy for observability. The realistic alternatives are (a) hand-roll a job_tracks table and trait — 1–2 sprints of work that only one engineer understands, or (b) buy into Telescope/Horizon/Sentry/Datadog — excellent for engineers debugging, wrong tool for product surface. This package occupies the missing middle: durable, queryable, application-facing job state you can render in an admin panel or expose to a customer.
• Where reliability work lands on the roadmap. Job-level history gives you the raw material to decide between "fix the top three failing job classes" and "rearchitect the queue" — a data-informed call instead of an incident-driven one.
• Support-tooling investment. "Where's my import?" is a top ticket category in data-heavy products. A job-status lookup by ID in an admin screen converts a human investigation into a self-serve or 30-second answer. Instrument ticket volume in that category before/after; it's a cheap ROI story.
• Data lifecycle and retention policy. A tracking table grows with every job dispatch. The decision to adopt is inseparable from the decision to prune (retain 30/90 days, archive failures, or sample successes). Force this conversation early — it's also the argument for not tracking every trivial job.
• Usage-based tiering and per-tenant economics. Job records per account are a ready-made metering primitive for plan limits on async/bulk operations, and a signal for which customers are abusing shared queue capacity.
• Audit/compliance posture. Immutable-ish records of what ran, when, and for whom can satisfy internal audit questions about background data processing without standing up a separate audit log.

When to Consider This Package

Adopt when: you're a Laravel app on the database or Redis queue; you already have (or need) customer- or support-visible job status rather than pure infrastructure monitoring; your team is small enough that maintaining a homegrown tracking table is real opportunity cost; you want a permissively licensed (MIT) dependency with a recent release and no lock-in — the data lands in your own database, so the exit path is a table and a trait, not a migration of vendors.

Be careful when: you need alerting, tracing, and error aggregation — this is not an APM. It's also worth weighing the adoption signal: 316 stars and zero dependents means a small, likely single-maintainer project. Vet it the way you'd vet any low-mileage dependency: pin the version, read the migration and trait, confirm Laravel/PHP version support against your upgrade cadence, and be prepared to fork or vendor it. For high-throughput queues, per-job writes are a real cost — track selectively, not universally.

Look elsewhere when: you want queue supervision and autoscaling (Horizon), local debugging introspection (Telescope), cross-service distributed tracing (OpenTelemetry/Sentry), or managed alerting (Datadog). Those solve a different problem and, notably, do not give you a product-facing status object. The honest positioning is complement, not replacement — and if your product never surfaces job state to a human, you don't need this at all.

How to Pitch It (Stakeholders)

To executives: a small, MIT-licensed, self-hosted addition that turns opaque background processing into a visible, queryable record. It unblocks customer-facing progress and retry experiences, cuts "is it stuck?" support load, and shortens incident triage — at roughly the cost of an integration ticket, with no vendor contract and no data leaving our database. Primary risk is maintenance of a low-adoption open-source dependency; mitigated by pinning, code review, and a trivial fork path.

To engineering: add the package, run the migration, apply the trait to the jobs we actually care about — not all of them. We get lifecycle timestamps, attempts, duration, and failure context in a table we control. It does not replace Horizon, Telescope, or Sentry, and it isn't a tracing system; treat it as the application-facing job state layer we've been re-implementing badly. Ship it behind an admin screen first, measure ticket deflection, then decide whether to expose it to customers.