Queued
Laravel emitted its JobQueued event for the selected job, and LatidoFlow created or matched a queued run.
Laravel queue monitoring
A queue driver can accept work while execution remains stuck. LatidoFlow preserves queued, started, retried or released, and terminal evidence for explicitly selected Laravel job classes.
When the application reports that a job was queued, LatidoFlow keeps the run in a queued state. If no worker-start event arrives after the configured dispatch delay and start SLA, the evaluator opens a queue-wait-timeout incident without pretending that the job already failed or finished.
If a worker later starts and the job succeeds, the same lifecycle can recover the monitor and resolve the incident. Stable idempotency keys keep the queued and running evidence connected.
Laravel emitted its JobQueued event for the selected job, and LatidoFlow created or matched a queued run.
A worker began processing under the same stable lifecycle key.
Intermediate evidence explains why terminal completion has not arrived yet.
The terminal event closes the execution path with a concrete outcome.
Automatic reporting is opt-in for exact job_class values. This keeps monitoring focused on business-critical jobs instead of ingesting every framework event by default.
The current limit is 60 ingestion requests per source IP each minute. A normal monitored job sends queued, start, and terminal evidence, which bounds automatic reporting to roughly 20 monitored jobs per minute per source IP before retries. Keep high-volume queues disabled until batched ingestion exists.
LatidoFlow is not presented as a replacement for queue throughput dashboards, worker balancing, or Redis queue operations. Laravel Horizon is purpose-built for those concerns. LatidoFlow adds selected job-level execution evidence and can connect a queue wait failure to incidents and a public service state.
Instrument a low-volume, business-critical job class and set a start timeout that reflects its real operating window.