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

# Run the platform from the console

> For Platform Super Admins: the overview, system health, switching feature flags, the cross-customer audit log, revoking keys, and granting the role.

A Platform Super Admin runs the whole deployment from the console's **Platform** group: **Overview**, **Customers**, **System health**, **Deployment settings**, **Audit log**, **Keys and connections**, and **Platform admins**. None of these screens shows a customer's content, a password or a secret.

This is platform administration. A customer's Owner or Administrator cannot see these screens, and MITHUNAI support staff cannot either; the platform refuses them. Your account must be listed in `ARUKZ_PLATFORM_ADMIN_ACCOUNT_IDS`, or another Platform Super Admin must have granted you the role on **Platform admins**.

## Overview

**Overview** is where the console opens for you. It counts, across every customer: customers by standing (active, on trial, trial ended, suspended, archived), accounts and seats, assistants, knowledge sources and documents, conversations and answers in the last day and week, ingestion jobs waiting, running and failed, and access requests waiting. It also lists this month's busiest customers; each one links to that customer's page, where **Usage** breaks their month down by where questions were asked. Choose another month there to see an earlier one.

## System health

**System health** shows what the deployment's readiness check reports, one word per dependency: the database, the rate-limit store and the embedding column. Beside them it shows the scheduler, the model providers, mail, how many tasks wait on the ingestion queue, ingestion jobs that failed, the build's commit, and whether the database is at the migration chain's head. It never shows why something failed; the reason is in the server log.

## Deployment settings

**Deployment settings** lists the products this deployment offers, whether each integration is configured (mail, Slack, Microsoft Teams, sign-on and each product's sign-on client, each model provider and each AI search engine), and every feature flag as on or off. It shows no configured value.

Some feature flags can be switched here. Each shows its state, whether the deployment's environment or a change made here decides it, and who changed it last.

1. Turn the flag's switch on or off, or choose **Reset to environment default** to undo a change.
2. Write why. The reason is required.
3. Confirm.

Every server and worker uses the new value within 15 seconds; nothing restarts. The change and your reason are in the audit log. Flags that cannot be switched here say why: sign-in and security settings, settings read when the service starts, and self sign-up, which requires legal review, stay in the deployment's environment.

## Audit log

**Audit log** lists audit events from every customer, newest first. Filter by organisation ID, actor, action or category, and by date; the last 30 days are shown unless you choose dates. Choose **Load more** for older events. A customer's Administrators export their own organisation's log from **Settings**; see [Audit log](https://docs.mithunai.com/administration/audit-log.md).

## Revoke a key or disconnect a tool

**Keys and connections** lists every customer's API keys, widget keys and AI-employee tool connections: the name, the organisation, the start of the key, its status, when it was made, and when it was last used. It never shows a secret.

1. Find the key or connection. Filter by organisation ID to narrow the list.
2. Choose **Revoke** or **Disconnect**.
3. Write why. The reason is required.
4. Confirm.

A revoked key stops working on its next request and cannot be turned back on; the customer makes a new one. A disconnected tool stops using that connection at once; the saved connection itself is kept. The customer's Administrators see the revocation, that a platform administrator did it, and your reason, in their own audit log.

## Grant or revoke Platform Super Admin

**Platform admins** lists everyone who can run the platform and where the role comes from: **Deployment settings** for an account in `ARUKZ_PLATFORM_ADMIN_ACCOUNT_IDS`, which cannot be changed on this screen, or **Granted** for one made here.

To grant the role:

1. Enter the address of an existing account that has verified its address, and choose **Grant**.
2. Write why, and enter your own password. The platform checks it once and does not keep it.
3. Choose **Grant**.

To revoke a grant, choose **Revoke** on its row, write why, enter your password and confirm. The person loses the role on their next request; their own customer seats are kept. You cannot revoke your own role, an account in the deployment's settings, or the last Platform Super Admin.

Every grant and revocation is in the audit log, and every Platform Super Admin is told by email when the deployment can send it. A wrong password counts toward the sign-in lockout for your address.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.