Users

Users shows who is using your app and who is having a bad time. Each row is one signed-in user with their request count, server errors and visit times. Use it when a customer reports a problem and you want to see exactly what they hit.

The list lives at /o/:org/projects/:project/users and a user at /o/:org/projects/:project/users/detail?id=42.

Identify your users

Users are keyed by user.id on SERVER spans with an HTTP method, the same spans that make up Requests. Requests without user.id are not counted anywhere on this page.

With the AdonisJS agent, call setUser once the request is authenticated. A small middleware placed after your auth middleware covers every route:

// app/middleware/unhandled_user_middleware.ts
import type { HttpContext } from '@adonisjs/core/http'
import type { NextFn } from '@adonisjs/core/types/http'
import { setUser } from '@unhandled/agent-adonisjs'

export default class UnhandledUserMiddleware {
  async handle(ctx: HttpContext, next: NextFn) {
    const user = ctx.auth.user
    if (user) {
      setUser({ id: user.id, email: user.email, name: user.fullName ?? undefined })
    }
    return next()
  }
}

setUser writes user.id, user.email and user.name on the active span and on the request's SERVER span, so it works from a controller or a nested service too. Only id is required. Email and name are for display: the list shows the latest values sent for each ID. Never put secrets in these fields.

Other SDKs set the same three attributes on the server span.

The list

Active Users Over Time plots distinct users per bucket.

The table lists up to 200 users, most requests first, with User, Requests, 5xx, First visit and Last visit. The table counts 5xx only, because a 4xx is often a validation error rather than something you broke. Search matches name, email or ID, case-insensitively, anywhere in the text.

User detail

The header shows the user's name, email or ID, then four cards: Requests (with the 5xx error rate as the hint), Server Errors (with client errors as the hint), Avg Latency (with P95 as the hint) and Last Visit (with the first visit as the hint).

• Activity by status stacks the user's requests per bucket into 2xx, 4xx and 5xx.
• Latency experienced plots the average and P95 response time this user saw.
• Requests lists their 100 latest requests in the range with Time, Request, Service, Status, Duration and a trace link.

All three follow the time range in the top bar, so widen it when the user reports something from last week.

Answering "a customer says checkout keeps failing"

1. Search the customer's email and open their row.
2. Look at Activity by status for 5xx bars around the time they reported.
3. Find the failing request in Requests and open its trace.
4. The failing span and any exception are in the trace view. The same exception is grouped in Issues with every other user it affected.