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

# The overview

> The first screen after you sign in: what is happening right now, and what the machines are doing about it.

**Overview** is where every sign-in lands. It answers one question — what is
happening right now — and it answers it from the switch rather than from the
database.

<Note>
  Everything on this screen is polled from the switch: live calls every three
  seconds, registrations every ten, nodes every fifteen. Live state has no
  other source of truth, and a cached list of channels is wrong the moment a
  call ends.
</Note>

There are two versions of the screen. An organisation sees its own world; an
operator sees the platform. They are the same endpoints, scoped on the
server, asking different questions.

## What an organisation sees

Four figures across the top:

| Tile                  |                                           |
| --------------------- | ----------------------------------------- |
| **Calls in progress** | live now, with the day's total beneath    |
| **Agents available**  | of how many human and how many virtual    |
| **Talk time**         | the day's, with the billable part beneath |
| **Balance**           | what is left, with **reserved** beneath   |

**Reserved** is credit held against calls that are in progress — money not
yet spent but no longer available. It is what stops a prepaid organisation
starting more calls than its balance can finish.

Below the figures: the calls in progress, the last few that completed, and
four charts — call volume, answer rate, spend and minutes, and why calls
ended. The last of those excludes normal clearing, because a chart in which
nine tenths of every bar is "the call ended normally" shows nothing.

## What an operator sees

The same shape, over every tenant: active calls against the fleet's total
legs, endpoints registered, the **transcode ratio**, and margin.

The transcode ratio is the one to watch. A call that relays costs the switch
almost nothing; a call it has to decode and re-encode is the most expensive
work in the system. The tile turns amber above a quarter and red above a
half.

### The nodes card, and the load brake

Each node reports itself: whether its control connection is up, how many
legs it is carrying against its limit, how much of its transcode budget is
in use, and how many AI audio streams are running.

When a machine is loaded it stops taking work, and the node says so in
words:

| Badge                                | What the node is doing                                                                 |
| ------------------------------------ | -------------------------------------------------------------------------------------- |
| **Refusing transcoded and AI calls** | calls the switch would have to *work* for are turned away; relayed calls still connect |
| **Refusing all new calls**           | nothing new is accepted until the load falls                                           |

This is the **load brake**, and it is deliberate: a node that keeps
accepting calls past its capacity degrades the audio of every call already
up. Refusing one caller is better than breaking two hundred conversations.

<Note>
  An organisation admin does not see this card, and does not need to — but it
  explains something they can see. A call refused by the brake comes back as
  **`503 node_busy`** with `Retry-After: 30`. Nothing rang and nothing was
  billed; sending the same request again is the right response. See [the
  fleet](/operator/fleet) for the limits themselves.
</Note>

## What it does not show

Anything that is not live. History, costs per call, who said what — those are
on their own screens. The overview is for the question you ask while
standing up.