> ## Documentation Index
> Fetch the complete documentation index at: https://docs.truthlocks.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Platform support console

> Monitor tenant health and manage support operations from the platform admin console.

The platform support console gives support staff a real-time view of tenant health signals, making it easy to identify tenants that need attention and initiate support sessions.

<Info>
  Access to the support console requires the **support\_admin** or **super\_admin** platform staff role. For details on how impersonation sessions work, see [Support access sessions](/security/support-access).
</Info>

## Health overview

The top of the support page shows four stat cards summarizing tenant health across the platform:

* **Total tenants** — total number of tenants.
* **Healthy** — tenants with no detected issues.
* **Warning** — tenants with elevated error rates or reduced activity.
* **Critical** — tenants with high error rates or no recent activity.

## Tenant health dashboard

Below the stats, a searchable, paginated table lists all tenants with live health signals. Each tenant row shows:

| Signal              | Description                                              |
| :------------------ | :------------------------------------------------------- |
| **Status**          | Tenant lifecycle status (active, suspended, etc.)        |
| **Health**          | Overall health — healthy, warning, critical, or unknown  |
| **API calls (24h)** | Number of API calls the tenant made in the last 24 hours |
| **Error rate**      | Percentage of API calls that returned errors             |

Health status is shown as a color-coded badge:

* **Green** — healthy, no issues detected.
* **Yellow** — warning, elevated error rate or reduced activity.
* **Red** — critical, high error rate or no recent activity.
* **Gray** — unknown, insufficient data to determine health.

Use the search bar to filter tenants by name or ID. Each row provides two action buttons: **View Details** to open the tenant's support detail page, and **Create Support Session** to start a new session immediately.

## Tenant support detail

Click a tenant row to open the tenant support detail page. The page displays four health signal cards (health status, last seen, API calls, and error rate) and a **Support Actions** toolbar with two options:

* **Create Support Session** — opens a dialog to start an impersonation session (see below).
* **Force Logout All Sessions** — immediately terminates all active user sessions for the tenant. Users will need to sign in again. A confirmation dialog appears before execution.

<Warning>
  Force logout is irreversible. All of the tenant's active sessions are terminated immediately.
</Warning>

### Creating a support session

<Steps>
  <Step title="Click Create Support Session">
    From the tenant support detail page, click **Create Support Session**.
  </Step>

  <Step title="Provide a reason">
    Enter a reason for the session (minimum 10 characters). This is recorded in the audit log.
  </Step>

  <Step title="Set the TTL">
    Choose how long the session should last, from 1 to 60 minutes. The default is 15 minutes.
  </Step>

  <Step title="Create">
    Click **Create Session**. You receive a confirmation with the session ID and expiration time.
  </Step>
</Steps>

<Tip>
  Always review the tenant's health signals before creating an impersonation session. Many issues — such as elevated error rates — can be diagnosed from the health dashboard without needing to access the tenant's data.
</Tip>

## Support session management

Navigate to **Support > View Sessions** to see all active and historical support sessions across the platform. The page opens with stat cards showing the count of active, revoked, and expired sessions.

Each session row shows:

* **Status** — Active, Expired, or Revoked.
* **Tenant** — the tenant the session was created for.
* **Scopes** — the permissions granted (for example, `read_only`).
* **Reason** — why the session was created.
* **Issued** — when the session was created.
* **Expires** — when the session automatically expires.

Active sessions can be revoked immediately if they are no longer needed. All session activity is recorded in the tenant's [audit log](/security/audit).

### Session detail and access logs

Click a session row to open the session detail page. The detail page shows two information cards:

* **Session details** — status, tenant ID, platform user ID, and the scopes granted.
* **Timing** — when the session was issued, when it expires, and (if applicable) when it was revoked.

Below the cards, the **Access Logs** table records every API request made during the session. Each entry includes:

| Column         | Description                               |
| :------------- | :---------------------------------------- |
| **Method**     | HTTP method (GET, POST, etc.)             |
| **Path**       | API path that was accessed                |
| **Status**     | HTTP response status code                 |
| **Request ID** | Unique request identifier for correlation |
| **Time**       | Timestamp of the request                  |

To revoke an active session, click **Revoke Session** at the top of the page. You can optionally provide a reason for revocation.

## Next steps

<CardGroup cols={2}>
  <Card title="Support access sessions" icon="shield" href="/security/support-access">
    How impersonation sessions work, including scopes and TTL.
  </Card>

  <Card title="Tenant management" icon="building" href="/guides/tenant-management">
    View and manage tenant lifecycle, plans, and settings.
  </Card>
</CardGroup>