Request Details

The Request Details page provides a comprehensive, per-request breakdown of everything Laritor has tracked. From high-level metadata (URL, timing, user, etc.) to a full, chronological list of events, you can drill into the specifics of any single HTTP request.

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

1. Header Grid: Core Request Metadata

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

Request URL & Method The full HTTP path (e.g., /api/posts/123) along with the request method (GET, POST, etc.).
Request Date Exact timestamp when Laritor recorded the incoming request.
Request Size (KB) Total size of the request payload, in kilobytes.
Response Size (KB) Total size of the response body, in kilobytes.
Duration Total processing time for this request, in milliseconds.
Memory Peak memory usage during request execution, in megabytes.
Status The HTTP status code returned (e.g., 200, 404, 500).
User Authenticated user identifier or email (if any) associated with this request. Empty if unauthenticated.
IP Address Client IP from which the request originated.
Controller The Laravel controller and action responsible for handling this request (e.g., PostController@show).
User Agent The full User-Agent header string sent by the client.

Each of these values helps you get an immediate snapshot of what happened during this request, without scrolling.

2. Optimize Using AI

Just above the event tabs, you will see a button labeled Optimize Using AI. Clicking this button opens a dialog where Laritor’s built-in AI engine analyzes the entire request sequence and generates tailored recommendations for optimizing this specific route. The AI review includes:

Identifying slow database queries that could benefit from indexing or refactoring.
Highlighting middleware or controller methods that contribute to high latency.
Suggesting cache improvements when repeated cache misses occur.
Calling attention to any redundant external API calls or opportunities to batch them.
Recommending code-level optimizations based on logged events, job dispatch patterns, or large payloads.

Tip: Use these AI recommendations as a starting point—each suggestion is based on the exact sequence of events captured for this request. Combined with the detailed event tabs below, AI insights can guide you toward faster, leaner routes.

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 lifecycle of this request. By default, the Timeline tab is active.

Available Tabs

Timeline (default)
Queries
Exceptions
Outbound Requests
Cache
Jobs
Logs
Mails
Notifications

Clicking on a tab loads the associated data set, enabling you to focus on only the subset of events or interactions you care about.

3.1 Timeline Tab

The Timeline tab shows every major phase and sub-event in the exact order they occurred, from the moment Laritor began processing the request until it completed. It is organized as a vertical, timestamped list of phases and individual operations:

Request Started
- Displayed on the left.
- Shows the timestamp when the request was first received.
Bootstrap
- Labeled “Bootstrap” on the left, with the total bootstrap duration on the right (e.g., 5 ms).
- Underneath this phase, each individual “bootstrap event” (service provider registrations, configuration loads, etc.) is listed in chronological order.
Middleware
- Labeled “Middleware” on the left, with middleware execution time on the right (e.g., 4 ms).
- Below that, each middleware event (authentication checks, custom middleware logic, etc.) appears in the order they ran.
Controller
- Labeled “Controller” on the left, with the controller/action execution time on the right (e.g., 303 ms).
- All events triggered within the controller method (database queries, cache hits, dispatching jobs, etc.) are shown here in the order they occurred.
- Each event card displays an icon to indicate its type (e.g., SQL query icon, cache icon, job icon, log icon) and a brief description.
View/Response
- Labeled “View / Response” on the left, with the view-rendering or response serialization time on the right.
- Any events that occur while building the response—such as rendering Blade templates, generating JSON, or sending HTTP responses—are listed here.
Request Completed
- Shown on the left with a timestamp on the right indicating when the final response was sent back to the client.

Timeline Event Types

Each event within a phase is grouped by category. Common event types include:

Queries (SQL statements executed)
Cache (cache hits or misses, including cache key names)
Exceptions (if an exception was thrown and caught)
Outbound Requests (calls to external HTTP services)
Jobs (jobs dispatched to the queue)
Logs (log messages written during execution)
Mails (emails sent via Laravel mailers)
Notifications (notifications sent via Laravel’s notification system)

Icons, color codes, and labels help you quickly identify high-latency sections or potential bottlenecks. For instance, a long-running database query will appear with a query icon and its own duration badge (e.g., 30 ms), while cache‐hit events show a “HIT” badge next to the cache key.

3.2 Queries Tab

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

Timestamp (relative or absolute)
Query Text (SQL statement)
Bindings (optional, if query bindings were recorded)
Duration (in milliseconds)
Connection Name (if multiple database connections exist)

Use this tab to diagnose slow queries, verify long‐running joins or scans, and identify opportunities for indexing or query optimization.

3.3 Exceptions Tab

If any exception was thrown during processing (whether caught or uncaught), it appears here. Each exception entry includes:

Timestamp
Exception Class & Message
Stack Trace (truncated or collapsed by default; expand to inspect)
File & Line Number

This view helps you quickly find unhandled errors or inspect the full stack trace to identify the root cause of an exception.

3.4 Outbound Requests Tab

Lists all external HTTP requests that your application made during this request. Each entry shows:

Timestamp
HTTP Method & URL
Status Code returned by the external service
Duration (time taken to complete the outbound call)
Response Size (if recorded)

Identify slow or failing third-party API calls that may be impacting your overall request latency.

3.5 Cache Tab

Displays all cache interactions within the request. For each cache event, you’ll see:

Timestamp
Type (e.g., “Cache Item,” “Cache Miss,” “Cache Flush”)
Cache Key (e.g., user_5_profile)
Duration (if measurable)
Hit/Miss Indicator (e.g., HIT or MISS)

Use this tab to verify that frequently used items are being cached correctly and to spot unexpected cache misses.

3.6 Jobs Tab

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

Timestamp
Job Class Name (e.g., SendWelcomeEmail)
Queue Name (e.g., emails)
Payload Metadata (if recorded)

Jobs dispatched asynchronously will not necessarily complete during this HTTP cycle—but this tab confirms that they were enqueued successfully.

3.7 Logs Tab

Lists all log entries written during the request’s lifecycle, including:

Timestamp
Log Level (e.g., DEBUG, INFO, WARNING, ERROR)
Log Message
Context Data (if any, in array form)

Review logs here to pinpoint informational or error messages without leaving the Laritor interface.

3.8 Mails Tab

Tracks all emails sent via Laravel’s mailing system during this request. Each mail event shows:

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

Use this to confirm that expected transactional or notification emails were dispatched.

3.9 Notifications Tab

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

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

This helps you verify that user notifications were triggered at the correct points.

4. Best Practices & Troubleshooting

Leverage AI Recommendations First
Before digging into raw events, click Optimize Using AI. The AI engine will highlight hotspots—such as slow queries, cache misses, or heavy controller logic—based on the events timeline.
Use the Timeline for Root-Cause Analysis
If a request is slow or fails, inspect the timeline’s longest sections (e.g., a high-duration controller phase). Then, dive into the Queries or Outbound Requests tab if database or external calls are responsible.
Validate Status & Size Metrics
Unusually large request or response sizes often correlate with performance issues. Use the Request Size and Response Size fields along with the Logs tab to identify oversized payloads or streaming errors.
Investigate Exceptions Quickly
The Exceptions tab surfaces errors without requiring you to open log files. For unhandled exceptions, review the stack trace to identify the failing code path immediately.
Monitor Cache Efficiency
Frequent cache misses can degrade performance. The Cache tab shows hits and misses in real time. Use that to refine cache keys or increase TTLs.
Confirm Job Dispatches
If queued jobs aren’t executing, verify in the Jobs tab that they were enqueued successfully. Look for missing or misconfigured queue connections if jobs never appear.
Verify Email & Notification Delivery
Use Mails and Notifications to ensure that transactional emails or other user messages were dispatched. Missing entries here often point to misconfigurations in mail driver or notification channels.

By leveraging the header grid, AI-driven recommendations, and the full suite of event tabs, Laritor’s Request Details view empowers you to diagnose performance bottlenecks, pinpoint errors, and optimize each route in your application with confidence.