Alerts Logs & Traces

Goal

Monitor platform health by tracking active user sessions and inspecting failed event deliveries through the Admin Console Observability section. By the end of this guide you will know how to browse and filter sessions across the realm, inspect session details such as connected clients and source IP addresses, terminate individual or multiple sessions, and locate failed events in DLT Management for further investigation.

Audience

This guide is intended for platform operators and security administrators who are responsible for monitoring user activity, responding to security incidents, and maintaining visibility into platform event delivery.

Prerequisites

• Access to the Admin Console with the sessions:read permission scope (required for viewing sessions).
• The sessions:delete permission scope (required for terminating sessions).
• The dlts:read permission scope (required for viewing DLT events).
• Familiarity with the Admin Console navigation. If you are new to the console, review the Admin Console overview first.

Before You Start

The Observability section in the Admin Console provides two operational tools:

• Sessions — Monitor all active user sessions across the realm. View session metadata, search by username, filter by session type, and terminate sessions when needed. This module is your primary tool for real-time user activity monitoring and incident response.
• DLT Management — Inspect failed platform event deliveries and replay them after resolving the root cause. This module surfaces events that could not be delivered to their target subscribers.

Both modules are accessible from the Observability group in the sidebar navigation.

Steps

1. Navigate to the Observability section

Open the Admin Console and expand the Observability group in the sidebar. You will see two sub-pages:

• Sessions — available at the route /observability/sessions
• DLT Management — available at the route /observability/dlt-management

Select Sessions to open the session monitoring page.

2. Monitor active sessions

The Sessions page displays a paginated table of all active sessions in the current realm. By default, the table shows 10 sessions per page and includes sessions of all types.

Each row in the table displays the following fields from the Session model:

Field	Description
username	The username of the authenticated user
userId	The unique identifier of the user
ipAddress	The IP address from which the session originated
start	Timestamp (in milliseconds) when the session was created
lastAccess	Timestamp (in milliseconds) of the most recent activity in the session
type	The session type: REGULAR for standard browser sessions, or OFFLINE for offline token sessions
clients	A map of client IDs to client names, representing the applications the user has accessed during the session

Filter by session type

Use the type filter to narrow the list. The available options are:

Filter value	Behavior
ALL	Displays both regular and offline sessions (default)
REGULAR	Displays only standard browser-based sessions
OFFLINE	Displays only sessions backed by offline tokens

Search sessions

Type a keyword into the search field to filter sessions. The search matches against session metadata such as the username, allowing you to locate a specific user's session quickly.

Paginate through results

Use the pagination controls at the bottom of the table to navigate between pages. The default page size is 10 sessions.

3. Inspect session details

Select a session row to review its full details. The detail view surfaces the following information:

• User identity — The username and userId identify who owns the session.
• Network origin — The ipAddress field shows where the session originated. Use this to detect logins from unexpected locations.
• Session duration — Compare the start and lastAccess timestamps to determine how long the session has been active and when the user last interacted with the platform.
• Session type — A REGULAR session represents a standard interactive login. An OFFLINE session represents a long-lived token grant, typically used by background services or mobile applications that need persistent access.
• Connected clients — The clients map lists every client application the user accessed during the session, displayed as client ID and client name pairs. A session connected to an unusually large number of clients may warrant investigation.
• Transient user flag — The transientUser field indicates whether the session belongs to a transient (temporary) user account.

4. Terminate sessions

The Admin Console provides three methods for terminating sessions. All termination actions require the sessions:delete permission scope.

Delete a single session

1. Locate the session you want to terminate in the sessions table.
2. Click the Delete action on the session row.
3. Confirm the deletion when prompted.
4. A success notification appears, and the session list refreshes automatically.

For offline sessions, the system passes the isOffline flag to ensure the correct session type is removed from the identity provider.

Bulk delete sessions

1. Select multiple sessions using the checkboxes in the session list.
2. Click the Delete action button.
3. The platform processes the deletions and returns a response with:
   • successCount — The number of sessions terminated.
   • failureCount — The number of sessions that could not be terminated.
   • failedSessions — An array listing each failed session ID and an optional reason for the failure.
4. A notification appears reflecting the outcome:
   • All sessions terminated: a success message displays the count.
   • Some sessions failed: a warning message displays both the success and failure counts.
   • All sessions failed: an error message appears.

Logout all sessions

1. Click the Logout All action.
2. Confirm the operation when prompted.

warning

The Logout All action terminates every active session in the current realm. This affects all users, not only the sessions visible on the current page. Use this action during security incidents that require an immediate platform-wide session reset, such as a credential compromise or a policy misconfiguration that granted excessive access.

5. DLT Management overview

The DLT Management module provides visibility into platform events that failed to reach their target subscriber endpoints. When an event delivery fails — for example, because the subscriber is unreachable or returns an error — the event is moved to a Dead Letter Topic (DLT) where it is preserved for diagnosis and replay.

From the DLT Management page at /observability/dlt-management, you can browse all failed events in a paginated table, search across event metadata, and sort by fields such as createdAt, updatedAt, or replayed. Selecting an event opens a detail view that includes the full event payload, delivery subscription information, and a chronological error history showing every failed delivery attempt.

For the complete guide on diagnosing failures, reading error history, and replaying events, see Decision Trace & Explainability.

Validation Scenario

Scenario

Confirm that you can locate a user session by username, verify its metadata, and terminate it.

Expected Result

The test user's session appears in the filtered list with the correct IP address and start time. After termination, the session no longer appears in the list, and the test user is logged out of the platform.

How to Verify

1. Log in to the platform as a test user (for example, user@example.com) from a known IP address (for example, 192.0.2.1).
2. Open the Admin Console and navigate to Observability > Sessions.
3. Type the test user's username into the search field.
4. Verify the session appears in the results with:
   • username matching the test user account.
   • ipAddress matching 192.0.2.1.
   • start timestamp matching the approximate login time.
   • type showing REGULAR.
5. Click Delete on the session row and confirm the action.
6. Verify:
   • UI evidence: A success notification appears. The session no longer appears in the list when you search again.
   • User evidence: The test user's browser session is invalidated. Attempting to access a protected page redirects the test user to the login screen.

Troubleshooting

Sessions not appearing in the list

Symptom: You expect to see active sessions, but the list is empty or the target session is missing.

Cause: The session type filter may be excluding the session. For example, if the filter is set to OFFLINE, regular browser sessions are hidden.

Resolution: Set the type filter to ALL to display both regular and offline sessions. Clear the search field to remove any active text filters. If the session still does not appear, verify that the user has an active session in the current realm.

Session data appears stale

Symptom: Session timestamps or client lists do not reflect recent activity.

Cause: The session list caches data for approximately one minute. Data may lag behind real-time activity by up to one minute.

Resolution: Wait for the cache to expire and the list to refresh automatically, or navigate away from the page and return to trigger a fresh query.

Logout All does not terminate a specific session

Symptom: After using Logout All, a session for a specific user still appears in the list.

Cause: The Logout All action terminates all sessions in the realm. However, if the user's client is configured with offline tokens, a new offline session may be re-established automatically by the client application.

Resolution: Check whether the persisting session has a type of OFFLINE. If so, delete it individually using the single-session delete action, and review the client configuration to determine whether offline tokens should be revoked.

Bulk delete reports partial failures

Symptom: The bulk delete response shows a failureCount greater than zero.

Cause: Some sessions may have already expired or been terminated by the user between the time you loaded the list and submitted the delete request.

Resolution: Review the failedSessions array in the response to identify which sessions failed and the associated reason. Refresh the session list and retry if the sessions still exist.

Next Steps

After familiarizing yourself with session monitoring and the Observability section, continue with these resources:

• Deep-dive into DLT Management — Read Decision Trace & Explainability for detailed instructions on diagnosing failed events and replaying them.
• Review main Admin Console workflows — Visit the Admin Console overview to explore other operational modules.

Related Docs

DLT Management Deep-Dive

Trace failed events, inspect error history, and replay events after resolving issues.

Admin Console Overview

Architecture and navigation overview for the Admin Console.

Observability — Operations

Platform telemetry pipeline: log collection, metrics, distributed tracing, and OTel export.

Audit Collector

Authorization decision event recording and compliance audit trail.