Queued Job Details
The Job Details page provides a comprehensive, per-job breakdown of everything Laritor has tracked for a single queued job. From connection and queue metadata to a full event timeline (including delay and wait times), you can inspect exactly how a job moved through the system and what happened during its execution.
Navigation: Click the View icon (👁️) next to any entry in the Queued Jobs index to open the Job Details page for that job.
1. Header Grid: Core Job Metadata
Section titled “1. Header Grid: Core Job Metadata”At the top of the Job Details page is a summary grid displaying all key identifiers and timing metrics for this queued job. These fields include:
-
Connection
The name of the queue connection (e.g.,redis
,database
,sqs
) on which the job was dispatched. -
Queue
The specific queue name or channel (e.g.,default
,high-priority
) where the job resides. -
Status
The current state of the job:- WAITING: Job is still in the queue and has not yet been processed.
- PROCESSED: Job completed successfully (exit code or return value indicated success).
- FAILED: Job encountered an uncaught exception or returned a failure state.
-
Dispatched At
Timestamp when the job was initially pushed onto the queue. -
Started At
Timestamp when the worker began executing the job. Blank if the job has not yet started. -
Completed At
Timestamp when the job finished execution. Blank if the job is still running or waiting. -
Duration
Total execution time of the job, in milliseconds (i.e., from Started At until Completed At). Blank if the job has not completed. -
Wait Time
Time the job spent waiting in the queue before execution began, in milliseconds (calculated asStarted At – Dispatched At
). Blank if the job has not started. -
Delay
If the job was dispatched with a delay (viadispatch()->delay()
), this shows that delay in milliseconds. Otherwise, it displays0
or “—”. -
Occurred On
Indicates where in your application code the job dispatch originated. Typical values include:- Request (if dispatched during an HTTP request)
- Command (if dispatched from an Artisan command)
- Scheduled Task (if dispatched from the scheduler)
- Another Queued Job (if this job was dispatched by a parent job)
This summary grid gives you an immediate snapshot of how the job entered the queue, where it ran, and its overall performance.
2. Tabbed Layout: Event Timeline & Related Data
Section titled “2. Tabbed Layout: Event Timeline & Related Data”Below the header grid, Laritor presents a set of tabs, each corresponding to a different category of events or side effects that occurred during the job’s lifecycle. By default, the Timeline tab is active.
Available Tabs
Section titled “Available Tabs”- Timeline (default)
- Queries
- Exceptions
- Outbound Requests
- Cache
- Jobs
- Logs
- Mails
- Notifications
Clicking on any tab filters the view to show only that event category, enabling you to drill into the subset of events most relevant to your investigation.
2.1 Timeline Tab
Section titled “2.1 Timeline Tab”The Timeline tab shows every major phase and event for this job, in the order they occurred. It is organized as a vertical, timestamped list of phases and individual operations:
-
Job Dispatched
- Displayed on the left, with the timestamp of Dispatched At on the right.
- Confirms exactly when the job was placed onto the queue.
-
Delay
- Labeled “Delay” on the left, with the configured delay duration on the right (e.g.,
5,000 ms
). - Indicates how long the job was scheduled to wait before even entering the ready queue. If no delay was set, this section may be omitted or show “0 ms”.
- Labeled “Delay” on the left, with the configured delay duration on the right (e.g.,
-
Wait for Processing
- Labeled “Wait for Processing” on the left, with total queue-wait time on the right (e.g.,
2,300 ms
). - Underneath, each micro-event related to queueing (e.g., job being released from a delayed queue, worker picking up the job) is listed in chronological order.
- Labeled “Wait for Processing” on the left, with total queue-wait time on the right (e.g.,
-
Job Started
- Labeled “Job Started” on the left, with the timestamp of Started At on the right.
- Marks the exact moment when the worker began executing the job.
-
Job Execution
- Labeled “Job Execution” on the left, with the total runtime for the job on the right (e.g.,
1,500 ms
). - All events triggered during the job’s business logic appear here in the order they occurred, including:
- Queries (SQL statements executed)
- Cache (cache hits, misses, writes)
- Exceptions (if any exceptions were thrown and caught during execution)
- Outbound Requests (HTTP calls to external services)
- Jobs (child jobs dispatched from within this job)
- Logs (log messages generated)
- Mails (emails sent via Laravel mailers)
- Notifications (notifications dispatched via Laravel channels)
- Each event card displays an icon indicating its type (e.g., SQL icon, cache icon, job icon, log icon) and a brief description or summary, along with any associated durations or status indicators.
- Labeled “Job Execution” on the left, with the total runtime for the job on the right (e.g.,
-
Job Completed
- Shown on the left with the timestamp of Completed At on the right.
- If the Status is
FAILED
, this section may highlight a failure badge, exit code, or exception indicator.
Timeline Event Types
Section titled “Timeline Event Types”- Queries: Detailed SQL statements, duration, and optional bindings.
- Cache: Cache key names, hit/miss status, and durations.
- Exceptions: Exception class, message, and stack trace (collapsed by default).
- Outbound Requests: HTTP method, target URL, status code, and duration.
- Jobs: Child job class names, queue metadata, and enqueue timestamps.
- Logs: Log level, message, and any contextual metadata.
- Mails: Mailable class, recipient addresses, and subject lines.
- Notifications: Notification class, channels, and recipients.
Icons, color-coding, and duration badges make it easy to identify performance bottlenecks (e.g., long-running queries or external calls) and to pinpoint exactly where a failure or exception occurred.
2.2 Queries Tab
Section titled “2.2 Queries Tab”The Queries tab lists every database query executed during this job’s execution, in chronological order. For each query, you will see:
- Timestamp (relative or absolute)
- Query Text (raw SQL statement)
- Bindings (if recorded)
- Duration (in milliseconds)
- Connection Name (if multiple database connections are used)
Use this tab to identify slow or inefficient queries that might be slowing down job execution.
2.3 Exceptions Tab
Section titled “2.3 Exceptions Tab”If the job threw any exceptions during its lifecycle, they appear here. Each exception entry includes:
- Timestamp
- Exception Class & Message
- Stack Trace (collapsed by default; expand to inspect)
- File & Line Number
This view helps you quickly locate the root cause of any job failures and see exactly where in the code the exception originated.
2.4 Outbound Requests Tab
Section titled “2.4 Outbound Requests Tab”Lists all external HTTP requests made by the job. Each entry shows:
- Timestamp
- HTTP Method & URL
- Status Code returned by the external service
- Duration (time taken to complete the HTTP call)
- Response Size (if recorded)
Use this information to diagnose slow or failing integrations with third-party APIs that might impact job performance.
2.5 Cache Tab
Section titled “2.5 Cache Tab”Displays all cache interactions during the job run. For each cache event, you’ll see:
- Timestamp
- Type (e.g., Cache Hit, Cache Miss, Cache Write)
- Cache Key (e.g.,
user_42_profile
) - Duration (if measurable)
- Hit/Miss Indicator
Use this tab to verify that caching is functioning correctly and to identify any unexpected cache misses that lead to repeated database calls.
2.6 Jobs Tab
Section titled “2.6 Jobs Tab”Shows every child job that was dispatched during the execution of this job. Each entry contains:
- Timestamp
- Job Class Name (e.g.,
SendNotificationJob
) - Queue Name (e.g.,
default
) - Payload Metadata (if recorded)
This helps you trace multi-level job workflows and confirm that dependent jobs were enqueued correctly.
2.7 Logs Tab
Section titled “2.7 Logs Tab”Lists all log entries created while the job was running. Each log entry includes:
- Timestamp
- Log Level (e.g.,
INFO
,ERROR
,DEBUG
) - Log Message
- Context Data (if provided)
Use this tab to trace informational or error messages, correlating them with specific points in the timeline.
2.8 Mails Tab
Section titled “2.8 Mails Tab”Tracks all emails sent during the job’s execution. Each mail event shows:
- Timestamp
- Mailable Class (e.g.,
InvoiceMail
) - Recipient Address(es)
- Subject Line
Verify that any emails triggered by the job were dispatched as intended.
2.9 Notifications Tab
Section titled “2.9 Notifications Tab”Displays notifications sent via Laravel’s notification system during this job run:
- Timestamp
- Notification Class (e.g.,
OrderShippedNotification
) - Channels (e.g.,
mail
,database
) - Recipient (user ID or model)
Confirm that notifications were triggered correctly and delivered to the intended recipients.
3. Best Practices & Troubleshooting
Section titled “3. Best Practices & Troubleshooting”-
Monitor Delay & Wait Times
If a job experiences a long Delay, verify that the intended delay was configured correctly and that no scheduler anomalies occurred. If Wait Time is excessive, investigate worker availability, queue throughput, or horizon/worker configuration. -
Use Timeline for Failure Diagnosis
When a job FAILED, start by examining the Exceptions and Logs tabs. Use the timeline to see exactly when during execution the exception occurred. -
Inspect Query Performance
Frequent or long-running queries can slow down job execution. Use the Queries tab to identify bottlenecks and optimize SQL (e.g., adding indexes or reducing result set sizes). -
Validate Cache Usage
Frequent cache misses can degrade performance. The Cache tab shows hits and misses. Adjust TTLs or cache key strategies to reduce redundant database calls. -
Confirm Child Job Dispatches
If your job spawns additional jobs, check the Jobs tab to ensure that child jobs were enqueued successfully with the correct queue and payload. -
Review External API Calls
Use the Outbound Requests tab to identify slow or failing third-party service calls. Consider retry logic, timeouts, or batching to improve reliability. -
Correlate Logs with Timeline
The Logs tab provides valuable debug information. Correlate log entries with specific timeline events to understand why a job may have hung or thrown an exception. -
Verify Email & Notification Delivery
Use the Mails and Notifications tabs to ensure that any triggered emails or notifications were sent. Missing entries here often point to misconfiguration in mail drivers or notification channels.
By leveraging the header grid, event tabs, and detailed timeline, Laritor’s Job Details view empowers you to diagnose delays, optimize background processing, and ensure that your queued jobs execute reliably and efficiently.