Outbound Requests

The Outbound Requests resource provides a centralized view of every external HTTP request your application issues. Use this page to identify slow or failed calls to third-party services, diagnose network or endpoint errors, and understand how external dependencies affect your application’s performance.

Navigation: Access Outbound Requests via the sidebar under the “Outbound Requests” section.

---

1. Outbound Requests Index Table

• Ordering: Entries are sorted by Occurred At in descending order (most recent first).
• Pagination: The table displays 25 rows by default. Click Load More at the bottom to load the next 25 entries.

1.1 Columns

1. Request Method

   • HTTP method used for the outbound call (e.g., GET, POST, PUT, DELETE).

2. Request URL

   • Full target URL of the external request (e.g., https://api.example.com/v1/users).

3. Occurrence

   • Indicates the context that triggered this external call, such as:
     • Request (e.g., a specific HTTP request that initiated the call)
     • Command (e.g., an Artisan command)
     • Scheduled Task (e.g., a scheduled job)
     • Queued Job (e.g., a background job)
   • Clicking the occurrence link navigates to the corresponding details page (e.g., Request Details) so you can see the full event timeline around this call.

4. Occurred At

   • Timestamp when Laritor recorded the outbound request.

5. Duration

   • Total time taken to complete the external HTTP call, in milliseconds (e.g., 120 ms).

6. Status

   • Outcome of the outbound call:
     • SUCCESS: Received a 2xx or acceptable status code.
     • FAILED: Received a non-2xx status code or encountered a network error/timeout.

Tip: Pay close attention to consecutive FAILED entries or calls with unusually high durations, as these can indicate downstream service degradation or misconfiguration.

---

2. Filters

Above the Outbound Requests table, use the following filter controls to refine the results:

1. Search

   • A free-text search field that matches against the Request URL.
   • Partial matches and substrings are supported (e.g., searching for “/users” will match any URL containing /users).

2. Date & Time Range

   • Select Start Date & Time and End Date & Time to show only calls that occurred within that window.

3. Duration

   • A numeric input (in milliseconds) to filter external calls whose execution time is above or below the specified threshold (e.g., show calls longer than 200 ms).

4. Status Filter

   • Clickable badges for each status: SUCCESS and FAILED.
   • Clicking a badge filters to calls with that outcome.

Tip: Combine Search and Duration filters to locate slow calls to a specific endpoint (e.g., all GET https://api.payment.com/* calls longer than 500 ms).

---

3. Load More

• By default, the table shows the 25 most recent external calls.
• Click the Load More button at the bottom to retrieve the next batch of 25 entries, ordered by Occurred At.
• This incremental loading ensures quick initial page loads while still providing access to your application’s entire history of outbound requests.

---

4. Best Practices

• Identify Slow Dependencies

  • Use the Duration filter to surface external calls that exceed an acceptable threshold. These may be candidates for caching, retries, or fallback logic.

• Track Failed Calls

  • Filter by FAILED status to quickly locate errors (timeouts, 4xx/5xx responses). Investigate underlying causes—network issues, expired credentials, or service outages.

• Correlate with Occurrence Context

  • Click on the Occurrence link to view the full timeline of the parent event (request, command, scheduled task, or job). This helps you understand whether the external call is part of a larger bottleneck or error cascade.

• Use Date Ranges for Deployment Analysis

  • Narrow the Date & Time Range to the period following a recent deployment. This can help you identify new or regressed external-call performance issues introduced by code changes.

• Group by Endpoint (Optional)

  • If your interface allows exporting data or grouping externally, consider grouping by base URL (e.g., api.example.com) to calculate aggregate metrics—average duration, failure rate—for each third-party service.

• Monitor Patterns Over Time

  • Load additional pages to extend your view into historical data. Identify trends such as gradually increasing latencies or rising failure counts over weeks or months.

By leveraging the Outbound Requests index, its filters, and the ability to drill into parent occurrences, you can proactively monitor, troubleshoot, and optimize your application’s interactions with external services.