Reproducible technical scenario
Laravel reported the job as queued. No worker ever started it.
A queued lifecycle event is not completion or a broker-durability guarantee. This automated product proof shows how LatidoFlow preserves a queued run, waits for its declared delay and start allowance, then opens a distinct incident when execution never begins.
Last reviewed: August 1, 2026
Lab evidence, not a customer story
The scenario is exercised by automated lifecycle coverage. It does not claim a customer outage, a production queue volume, or a measured reduction in response time.
Direct answer
A delayed start becomes its own incident, not a generic failed job.
Laravel's JobQueued event records the job identity, dispatch time, declared delay, and configured start allowance. It is application lifecycle evidence, not proof of durable broker acceptance. LatidoFlow does not alert while that legitimate waiting window remains open.
After the declared delay plus start deadline expires, evaluation opens one queue_wait_timeout incident. The run remains queued, so the evidence does not pretend the job started, failed inside its handler, or disappeared from history.
If a worker starts the same run late and it later completes successfully, LatidoFlow resolves the queue-wait occurrence and returns the linked status state to healthy.
Verified timeline
The queued record survives the timeout.
Queued
Laravel emits JobQueued; the lifecycle run records that event and the intended delay.
Waiting
Evaluation respects the declared delay and start allowance before deciding the worker is late.
Incident
One queue-wait timeout opens while the underlying run remains queued.
Late recovery
A matching start followed by success recovers the same occurrence instead of creating a second history.
What this proves
- Dispatch delay is included before the start deadline is evaluated.
- Repeated evaluation does not open duplicate incidents for the same wait occurrence.
- The queued state remains available for an eventual worker start.
- A late start and valid completion resolve the queue-wait incident.
- The linked public status state follows the active incident.
Current boundary
- This is lifecycle proof for exact, allowlisted Laravel job classes, not visibility into every queue internals metric.
- The automatic queue path is intended for low-volume, business-critical work. Its present request-rate ceiling is roughly 20 monitored jobs per minute per source IP when each job emits three lifecycle events.
- High-throughput telemetry still requires a batched ingestion path before this can replace broad queue observability.
- No throughput improvement, worker auto-remediation, or customer outcome is claimed.
- Public status-page email subscriptions are not implemented.
Continue through the queue lifecycle
Monitor the gap between dispatch and execution.
Choose a low-volume, business-critical Laravel job and make its start deadline explicit instead of treating a queued event as completion.