Command Details

The Command Details page provides a comprehensive, per-command breakdown of everything Laritor has tracked. From high-level metadata (command name, timing, exit code, etc.) to a full chronological list of events, you can inspect the lifecycle of any Artisan command execution in detail.

Navigation: Click the “View” icon (👁️) next to any row in the Commands index to open the Command Details page for that entry.

---

1. Header Grid: Core Command Metadata

At the top of the Command Details page is a summary grid that surfaces all of the key metrics and identifying fields for this command execution. These fields include:

• Command
  The full Artisan command name (e.g., queue:work, cache:clear, or any custom console command).

• Started At
  Exact timestamp when Laritor recorded the start of the command.

• Completed At
  Timestamp when the command finished execution. If the command is still running, this field may be blank until it completes.

• Duration
  Total execution time for this command, in milliseconds.

• Exit Code
  The exit status returned by the command process (e.g., 0 for success, any non-zero value for failure).

Each of these values gives you an immediate snapshot of how the command ran—allowing you to quickly identify long-running executions or non-zero exit codes.

---

2. Tabbed Layout: Event Timeline & Related Data

Below the header grid, the UI is organized into a set of tabs. Each tab corresponds to a different category of events or side effects that occurred during the command’s lifecycle. By default, the Timeline tab is active.

Available Tabs

1. Timeline (default)
2. Queries
3. Exceptions
4. Outbound Requests
5. Cache
6. Jobs
7. Logs
8. Mails
9. Notifications

Clicking on a tab loads the associated data set, enabling you to focus on the subset of events relevant to that command execution.

---

2.1 Timeline Tab

The Timeline tab shows every major phase and sub-event of the command execution in the exact order they occurred, from when Laritor first detected the command start until it completed. It is organized as a vertical, timestamped list:

1. Command Started

   • Displayed on the left.
   • Shows the timestamp when the command began.

2. Bootstrap

   • Labeled “Bootstrap” on the left, with the total bootstrap duration on the right (e.g., 15 ms).
   • Underneath this phase, each individual bootstrap event (service provider registrations, configuration loads, IoC container setup, etc.) is listed in chronological order.

3. Command Execution

   • Labeled “Command Execution” on the left, with the total command/runtime duration on the right (e.g., 2,345 ms).
   • All events triggered during the command’s main logic appear here in the order they occurred, including:
     • Queries (SQL statements executed)
     • Cache (cache hits or misses)
     • Exceptions (if any exceptions were thrown and caught)
     • Outbound Requests (HTTP calls to external services)
     • Jobs (jobs dispatched to the queue)
     • Logs (log messages generated)
     • Mails (emails sent during execution)
     • Notifications (notifications dispatched via Laravel)
   • 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.

4. Command Completed

   • Shown on the left with a timestamp on the right indicating when the command process exited.
   • If the exit code is non-zero, this phase may highlight a failure status.

Timeline Event Types

• Queries: Detailed SQL statements, durations, and optional bindings.
• Cache: Cache hits/misses and cache key names.
• Exceptions: Exception class, message, and stack trace (if recorded).
• Outbound Requests: HTTP method, URL, status code, and duration.
• Jobs: Job class names and queue metadata when enqueued.
• Logs: Log level, message, and any context data.
• Mails: Mailable class, recipients, and subject lines.
• Notifications: Notification class, channels used, and recipients.

Icons, color codes, and duration badges help you identify performance bottlenecks, failed operations, or unexpected delays within the command’s flow.

---

2.2 Queries Tab

The Queries tab lists every database query executed during this command, in chronological order. For each query, you will see:

• Timestamp (relative or absolute)
• Query Text (raw SQL)
• Bindings (if captured)
• Duration (in milliseconds)
• Connection Name (if the command uses multiple database connections)

Use this tab to identify slow or inefficient queries invoked by the command’s logic.

---

2.3 Exceptions Tab

If the command threw any exceptions during execution, they appear here. Each exception entry includes:

• Timestamp
• Exception Class & Message
• Stack Trace (collapsed by default, expandable on click)
• File & Line Number

This view allows you to quickly spot uncaught or caught errors that occurred during the command’s runtime.

---

2.4 Outbound Requests Tab

Lists all external HTTP requests made by the command. 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 third-party interactions invoked by the command.

---

2.5 Cache Tab

Displays all cache operations performed during command execution. For each cache event, you will see:

• Timestamp
• Type (e.g., “Cache Hit,” “Cache Miss,” “Cache Write”)
• Cache Key (e.g., reports:daily_summary)
• Duration (if measurable)
• Hit/Miss Indicator

Review this tab to ensure that caching behavior aligns with expectations—spotting unnecessary cache misses or verifying cache hits.

---

2.6 Jobs Tab

Shows every job that was dispatched (pushed to the queue) during this command run. Each job entry contains:

• Timestamp
• Job Class Name (e.g., GenerateReportJob)
• Queue Name (e.g., default)
• Payload Metadata (if recorded)

This helps you confirm that background tasks were enqueued properly as part of the command’s workflow.

---

2.7 Logs Tab

Lists all log entries written while the command was running, including:

• Timestamp
• Log Level (e.g., INFO, WARNING, ERROR)
• Log Message
• Context Data (if provided)

Use this tab to trace informational messages or error logs without leaving the Laritor interface.

---

2.8 Mails Tab

Tracks all emails sent during the command’s execution. Each mail event shows:

• Timestamp
• Mailable Class (e.g., DailySummaryReportMail)
• Recipient Address(es)
• Subject Line

Verify that any scheduled or triggered emails were actually dispatched by the command.

---

2.9 Notifications Tab

Displays notifications sent through Laravel’s notification channels (database, mail, Slack, etc.) during the command run:

• Timestamp
• Notification Class (e.g., ReportReadyNotification)
• Channels (e.g., mail, database)
• Recipient (user ID or model)

This tab helps ensure that user notifications were triggered correctly as part of the command’s logic.

---

3. Best Practices & Troubleshooting

• Use the Timeline for Root-Cause Analysis
  When a command is slow or fails, start by examining the timeline’s longest phases (e.g., a heavy bootstrap process or a long-running “Command Execution” section). Then, dig into the Queries or Outbound Requests tab to identify database or external API bottlenecks.

• Monitor Exit Codes
  A non-zero Exit Code often indicates an error. If the exit code is not 0, review the Exceptions tab and Logs tab to identify which errors were thrown and where.

• Validate Query Performance
  Frequent or slow queries can significantly slow down a command. Use the Queries tab to spot inefficient SQL or missing indexes that you can optimize.

• Inspect Cache Utilization
  If your command relies heavily on caching (e.g., for generating reports), verify in the Cache tab that keys are being stored and retrieved as expected, avoiding cache misses that can degrade performance.

• Verify Job Dispatches
  If the command’s purpose is to enqueue background jobs (for batch processing or notifications), confirm in the Jobs tab that jobs are dispatched to the correct queue with the expected payload.

• Review Logs for Context
  The Logs tab provides valuable context. Use it to correlate informational messages or error logs with specific points in the timeline, helping you understand the command’s flow.

• Confirm Email & Notification Delivery
  Use the Mails and Notifications tabs to ensure that any triggered emails or notifications actually went out. Missing entries here could point to misconfigured mail drivers or notification channels.

---

By leveraging the header grid and the full suite of event tabs, Laritor’s Command Details view empowers you to diagnose long-running or failing console commands, optimize SQL and caching behavior, and ensure that background jobs, emails, and notifications execute as intended.