Users

The Users resource provides a paginated list of every registered user in your application. From this page, you can search for specific users, view their profile details, and inspect their activity across all monitored resources (requests, queries, jobs, etc.).

Navigation: Access Users via the sidebar under the “Users” section.

---

1. Users Index Table

The Users index displays 25 entries per page, ordered by User ID or default sorting criteria. Scroll down and click Load More to retrieve additional users.

1.1 Columns

1. Avatar
   • The user’s avatar or profile image (if available).
2. User ID
   • The unique identifier for the user (e.g., 42).
3. User Name
   • The full name or display name of the user (e.g., Jane Doe).
4. User Email
   • The email address associated with the user (e.g., [email protected]).

Tip: If avatars are missing, confirm that your application is correctly supplying a Gravatar URL or local image path in the user profile.

1.2 Search Filter

Above the table, a Search field allows you to filter users by name or email. Partial matches and substrings are supported (for example, typing “doe” matches both [email protected] and John Doe).

Tip: Combine the search term with pagination to quickly locate users in large deployments.

1.3 Row Interactivity

• Clickable Rows
  • Clicking any row navigates to that user’s User Details page, where you can inspect their profile and activity across all resources.

---

2. User Details

Clicking a user entry opens the User Details page. This view is divided into two main sections:

1. User Summary Card
2. User Activity Tabs

2.1 User Summary Card

At the top of the User Details page, a summary card displays:

• Avatar
• User ID
• User Name
• User Email

This compact header provides immediate context on the user whose data you are reviewing.

Tip: If you do not see an avatar, verify that the user profile includes a valid image URL or Gravatar hash.

2.2 User Activity

Below the summary card, an activity section contains a series of tabs—one for each monitored resource. Each tab lists that resource’s records associated with the current user. In other words, only events or entries “originating” from this user (e.g., requests they made, queries executed under their session, jobs they triggered) will appear.

2.2.1 Available Tabs

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

Click a tab header to view the corresponding data subset. For example, the Requests tab lists only the HTTP requests where this user was authenticated and made that request. Similarly, the Mails tab shows all emails sent on behalf of (or triggered by) this user.

Tip: The tab labels match those used in the standalone resource pages, but here they are scoped to a single user’s context.

2.2.2 Shared Filter Controls

Above the activity tabs, a set of filters applies to whichever tab is active. Common filters include:

• Search
  • For free-text searching within the active tab’s primary column (e.g., request URL in Requests, query text in Queries, log message in Logs).
• Date Range
  • Select a Start Date & Time and End Date & Time to limit displayed entries to those that occurred within the specified window.

Below are additional filters specific to certain tabs:

• Queued Job Filter (applies when Jobs tab is active)
  • A dropdown or autocomplete to filter job records by job class or identifier.
• Request Duration Filter (applies when Requests tab is active)
  • Numeric input (milliseconds) to show only requests above or below a certain execution time.
• Request Method Filter (applies when Requests tab is active)
  • Selectable badges for GET, POST, PUT, PATCH, DELETE to filter by HTTP method.
• Request Status Filter (applies when Requests tab is active)
  • Selectable badges for 2xx, 3xx, 4xx, 5xx to filter by HTTP status code class.
• Job Status Filter (applies when Jobs tab is active)
  • Selectable badges for WAITING, PROCESSED, FAILED to filter job records by status.

Tip: Combining search, date range, and status filters helps you pinpoint a user’s slowest requests or most frequently failing jobs during a specific period.

2.2.3 Activity Tab Content

Each tab’s table follows the same pagination pattern:

• Pagination & Ordering

  • Shows 25 entries per page, ordered by the primary timestamp (for example, Executed At for Queries or Occurred At for Logs) in descending order.
  • Click Load More at the bottom to retrieve older entries.

• Columns (Per Resource)

  • Requests: URL, Request Date, Duration, Memory, Status, and a View link to Request Details.
  • Queries: Executed At, Query Text, Duration, Occurrence (link to Request Details), and an Optimize with AI link.
  • Exceptions: Exception Class, Exception Message, File & Line, Occurred On, with a View link to Exception Details.
  • Outbound Requests: Method, URL, Occurrence, Occurred At, Duration, Status (SUCCESS/FAILED).
  • Jobs: Job Class, Dispatched At, Processed At, Wait Time, Duration, Status (WAITING/PROCESSED/FAILED).
  • Cache: Cache Key, Occurrence, Occurred At, Hit/Miss.
  • Logs: Date, Log Level, Message, Occurrence (link to Request Details).
  • Mails: Sent At, Mailable, To, Subject, Occurrence.
  • Notifications: Sent At, Notification Class, Notifiable, Occurrence.

Tip: Each table column name and ordering mirrors what you see on the standalone resource pages—just scoped to the current user.

---

3. Best Practices

• User-Centric Troubleshooting

  • When investigating a user-reported issue, start on the User Details page. Filter the Requests tab by status 5xx to see if that user experienced any errors recently, then drill into Exceptions to identify root causes.

• Identify Query Patterns

  • Use the Queries tab to see which SQL statements a given user triggered. Filter by Duration to spot slow queries tied to that user’s actions.

• Track Email & Notification History

  • The Mails and Notifications tabs let you verify that the user received critical transactional emails or notifications (e.g., password resets, order updates). Filter by Date Range around the event in question (e.g., “I never got my invoice email yesterday”).

• Correlate with Scheduled Jobs

  • If a user’s action triggers a background job (e.g., generating a report), check the Jobs tab for that user. Filter by FAILED to see if the job encountered an error.

• Monitor Cache Usage

  • In the Cache tab, look for repeated MISS entries for keys associated with that user (for example, user_42_profile). Frequent misses may indicate that the user’s data is not being cached properly.

• Search Across All Activity

  • Use the shared Search field to find a keyword (e.g., an order ID or transaction token) that might appear in requests, logs, or exceptions. Because each tab shares the same search bar, you can quickly scan all user-related data for that term.

• Temporal Investigation

  • When a user reports a slow operation at a specific time, filter all tabs by that Date Range to reconstruct the full sequence of events—requests, queries, logs, and any errors that followed.

• Leverage Occurrence Links

  • Clicking an Occurrence in any table (for example, an exception occurrence) will take you to the context where the user triggered that event (such as a particular request). This helps you understand the broader execution path.

---

By leveraging the Users index and the detailed User Details view with activity tabs, Laritor enables you to perform user-centric analyses—tracing user actions, diagnosing performance issues, and verifying communications—all from a single, unified interface.