User X changed the order -except a queued job did. Here's the missing piece in Laravel audit logs.

Roman_14K — Mon, 15 Jun 2026 08:55:52 +0000

An order suddenly moved to refunded.

You open the audit log and see:

Order #42 updated
By: System
Changed: status = refunded

Great.

But who actually clicked the button?

Support? The customer? An admin? A scheduled task? Another job?

The audit trail has no answer.

That problem is what led me to build Yammi Audit Log.

The problem with audit logs in queue-heavy applications

Most Laravel audit packages are good at answering one question:

What changed?

In modern applications, that's often not enough.

A typical flow looks like this:

HTTP request
    ↓
Service
    ↓
Queue
    ↓
Job
    ↓
Model update

By the time the database row is updated, the actual write is being performed by a queue worker.

The audit log ends up saying something like:

Changed by: System

Changed by: Queue Worker

Technically correct.

Practically useless.

During an incident, the question people actually ask is:

Who initiated this change, and what execution path led to it?

Tracking provenance instead of just changes

Yammi Audit Log records three separate concepts for every change.

Actor

Who directly executed the write.

For example:

{
  "type": "job",
  "label": "ChargeOrder"
}

Actors can be:

user
job
command
scheduler
system

Origin

Who started the entire chain.

Imagine a user clicks "Pay".

That dispatches a job.

The job dispatches another job.

The final database write is executed by a queue worker, but the origin remains:

{
  "type": "user",
  "label": "John Doe"
}

Correlation ID

A single identifier shared across the entire execution chain.

Request
  ↓
Job A
  ↓
Job B
  ↓
Order #42 updated

That correlation ID allows you to reconstruct the full cascade.

[trace screenshot]

Now the audit log answers:

What caused this change?

instead of only:

What code wrote this row?

How it works

The implementation is intentionally simple.

The package listens globally to Eloquent model events:

created
updated
deleted
restored

When a change occurs:

A field-level diff is built.
Sensitive values are redacted (password, token, api_key, etc.).
The current actor is resolved.
The origin context is serialized into queued jobs.
A correlation ID ties the entire chain together.
An audit record is written.

No per-model registration is required for basic auditing.

User::first()->update([
    'name' => 'John Doe',
]);

The change is captured automatically.

[dashboard screenshot]

A few things built on top of that context

Once every change carries execution provenance, some interesting features become possible.

Tamper-evident history

Optionally hash-chain every record and verify integrity later.

php artisan audit-log:verify

Time Machine

Reconstruct the exact state of a record at any point in time.

AuditLog::stateAt(
    Order::class,
    42,
    '2026-03-03'
);

Anomaly Detection

Detect suspicious patterns such as:

change bursts
mass deletions
off-hours activity
unusually large write cascades

Because the package already understands the execution chain, it can reason about behavior, not just rows.

Try it

Installation takes a couple of minutes:

composer require romalytar/yammi-audit-log-laravel

php artisan migrate

php artisan audit-log:ui enable

Then open:

/audit-log

and start seeing not only what changed, but how that change got there.

GitHub: https://github.com/RomaLytar/yammi-audit-log

If this kind of execution traceability is something you've missed in Laravel, I'd love to hear your feedback.

I built a Laravel queue monitoring tool because I got tired of not knowing what my jobs actually do

Roman_14K — Sun, 19 Apr 2026 16:12:58 +0000

At some point I realized I don’t really understand what’s going on with my queues.
I mean, yeah:

jobs are running
workers are alive
logs exist somewhere

But if I try to answer simple questions:

did this job actually do what it was supposed to do?
or did it just “successfully complete”?
where do things silently break?

— I don’t really have good answers. The most annoying part — silent failures. There’s a type of bug that’s especially frustrating.
A job:

runs
throws no errors
finishes with success
…and does absolutely nothing.
I thought it was rare, but once I started digging, I found several cases like this. What helped me spot them was looking at execution time.
Something like: normally the job takes ~500ms, sometimes it finishes in 5ms, that’s… suspicious 🙂
That’s how I found jobs that were “successful” but effectively doing nothing. At some point I just wanted a clear view. Nothing fancy.
Just open a page and understand:
what’s happening right now
what’s failing
what looks weird

Plus a few practical things:

see all retries
understand failure reasons
group recurring errors
retry not just one job, but many
sometimes fix the payload and re-run

And of course alerts:

Slack
Webhook
PagerDuty for critical stuff So I built a small package, installation is basically:

composer require romalytar/yammi-jobs-monitoring-laravel php artisan migrate

Then you just open:

/jobs-monitor
No heavy setup, it just works.
What it actually shows. The main idea is: not just status, but behavior.
You can open any job and see:

all attempts
errors
execution time for each try
Which already gives way more insight than just “failed / success”.
There’s also some basic stats:
which jobs fail the most
slowest jobs
retry rate

Failed jobs (DLQ) are actually usable:

retry
edit & retry (JSON payload)
bulk operations

One thing I personally like a lot — error grouping.
Instead of scrolling through identical stack traces, you see grouped failures and immediately understand:
“ok, this all comes from the same issue”.
And probably the most useful part — anomaly detection.
If a job suddenly:

becomes much slower
or suspiciously fast

—it gets flagged.

Those “too fast” cases are often silent failures.
Also included:

worker heartbeat (you see when workers disappear)
scheduled task monitoring
alerts (Slack / Webhook / PagerDuty / etc.)

The whole idea is pretty simple Not to build “another tool”.
But to answer one question: what is actually happening in my queues?
Would love some feedback
If anyone tries it, I’d be really interested in:

what’s missing
what feels unnecessary
what works well in real projects

Here’s the repo if you want to check it out:
https://github.com/RomaLytar/yammi-jobs-monitoring-laravel

DEV Community: Roman_14K