---
description: >-
  Use Analyzer to review coding-agent sessions, inspect security decisions, and manage Watcher monitors and organization settings.
---

> Part of the Watcher docs. Index of all pages, with summaries: https://watcher-docs.apolloresearch.ai/llms.txt
> Before upgrading Watcher, read the release pages and full changelogs for every version crossed: https://watcher-docs.apolloresearch.ai/releases/index.md
> Found an issue with this page? Report it: https://github.com/ApolloResearch/watcher-bin/issues/new?title=Docs%20feedback%3A%20Analyzer&body=Page%3A%20Analyzer%0AURL%3A%20https%3A%2F%2Fwatcher-docs.apolloresearch.ai%2Fconcepts%2Fanalyzer%2F%0A%0A

# Analyzer

The Analyzer is Watcher's web dashboard. Your team uses it to inspect sessions,
tool-call decisions and grades. These records come from the
[Watcher client](../client/index.md) or [gateway hooks](../api/hooks.md).

On Apollo's hosted cloud it is at `https://app.apolloresearch.ai`. On a
self-hosted deployment it is your own hostname. This is the one your reverse
proxy fronts. Anyone your deployment authenticates can sign in. See
[Organization settings](organization-settings.md) for how members and admins are
distinguished.

## What you can do in it

The Analyzer has four areas everyone sees:

- **Dashboard.** Every figure covers the sessions you may read: the whole
  organization if you may read other people's sessions, otherwise your own.
  The view starts with the tool calls Watcher approved
  without asking anyone during the selected period. Next to these is the smaller
  number that needed a decision. Tools that always go to a person sit outside
  both groups. For example, a request for your input. Watcher expects those to
  reach you. The total shown is those two groups rather than every call in the
  period. Calls allowed because grading failed do not count as automatic
  approvals. A failure-policy block still counts as blocked; in observe mode
  it counts as would have blocked. The automatic-approval and decision groups,
  and the flow leaving them, are drawn at different scales. A working deployment
  approves thousands of calls for every one it stops. At a single scale the
  outcomes would be too thin to see. The width of
  the flow out of the first block is not in proportion to the block itself.

  Calls that needed a decision continue to their outcomes. Enforced calls reach
  **Blocked** or **Allowed by a person**. Calls reviewed in
  [observe mode](blocking-and-trailing-review.md#enforcement-modes) reach
  **Would have blocked** or **Would have asked a person**. The first block reads
  **Watcher would have auto-approved**. This is because Watcher acts on nothing
  in that mode. A period can show both groups. This happens when it spans a mode
  change. When only one group has outcomes, the flow goes directly to those
  outcomes.

  The flow sits under **Coverage**. This also shows how many sessions arrived in
  the period and how many of them were deep reviewed.

  Under **Findings** below it, a [severity](#severity) selector governs everything
  in that section. This includes the **Sessions to Review** list. The list holds
  sessions at or above the selected severity with recently blocked ones first.
  It also includes a count of those sessions. Organization-wide dashboards
  show a count of the people behind them too. The daily trend bars are split into
  the sessions that met that severity and the rest of the day. Nothing under
  Coverage changes when you move that
  selector. How much Watcher saw and checked does not depend on what it found.

  The two counts answer different questions. The sessions count is how many
  sessions in the period reached the selected severity. It includes their share
  of every session in the period. **Affected Users** is how many people those
  sessions belong to. It appears only when you may read sessions across the
  organization. The denominator is the people who ran any session in the
  period. One person's ten flagged sessions count once. A session recorded
  without a known owner counts in the session figures and in neither user
  figure. Each count also carries the change in its rate against an earlier
  period. That period is named on the card. The Affected Users change reads as
  unavailable when either period recorded no users to compute a rate from.

- **Sessions.** The queue. Every recorded
  [session](sessions-and-trajectories.md) with its grades. You can filter to
  start from the ones that matter rather than the newest. The **Source** filter
  selects how messages reached Watcher: Watcher Live, Aperture, Gateway,
  Watcher SDK, or Hooks API. The last three split other
  [gateway hook](../api/hooks.md) messages by the session's conversation ID.
  **Gateway** covers the gateway examples, whose IDs start with a prefix such
  as `litellm:`. **Watcher SDK** covers registered SDK coding agents, such as
  `github-copilot-cli:` for Copilot. **Hooks API** covers any other hook
  integration, including one that sends no conversation ID. Your own agent
  sending gateway hooks through the Watcher SDK with its own conversation ID
  shows Hooks API, not Watcher SDK. LiteLLM traffic without an
  `x-watcher-session-id` header has no ID, so it shows Hooks API too. Select
  all three to see every non-Aperture gateway hook session. These labels do
  not change how Watcher records or reviews a session.
  Use the **Platform** filter to limit results to a coding agent, such as Codex.
  Selecting several sources
  matches any of them; other filters must also match. Badges reflect retained
  messages, so one session can show several sources. Scrubbed sessions have no
  source badges and do not match a source filter. See
  [ingestion sources](../api/python-sdk.md#filter-by-ingestion-source) for exact
  source keys and retention behavior. Opening a session gives you
  its transcript. This shows what the agent did, turn by turn. The grades and
  the [blocking review](blocking-and-trailing-review.md) decisions are shown
  against the tool calls that produced them.
- **Tool calls.** The same decisions as rows of their own. One row per tool call
  Watcher recorded a blocking-review decision about, across sessions. Filter by
  severity, by what Watcher did, by tool, by person, and by date. Sort by
  severity, decision, tool, or time. It starts on critical and high calls, worst
  first. Calls Watcher decided without scoring them are their own **Not scored**
  filter. This is different from a severity band. Clearing the severity filter
  shows every call, scored or not. Selecting **Not scored** on its own shows
  only the calls without a score. Failed grading has no severity, even when
  an earlier review stage produced a score. These calls remain in the unscored
  list and session transcript, with their recorded permission outcome. A valid
  score from an earlier stage still applies when later grading was skipped on
  purpose. A row whose session content has been
  [scrubbed](organization-settings.md#data-retention) keeps its outcome, the
  person, and the time. It says nothing about the tool.
- **Monitors.** [Managed monitor](graders.md#monitors) descriptions are visible
  to every organization member. They are the default view when the server
  supports them. Custom instructions still require organization-settings access
  to read and write access to edit. **Legacy & custom monitors** lists the
  [graders](graders.md) your organization uses. This includes older built-in
  rubrics whose model and prompt are separate from managed monitors. Custom
  monitor is the Analyzer's name for a grader. Each row is marked `live` or
  `async`. `live` means eligible to run as a
  [blocking review](blocking-and-trailing-review.md) stage. `async` means it
  only grades after the fact. The section is marked deprecated. For organization
  policy on managed live monitors, prefer
  [custom instructions](graders.md#monitors). The graders listed in the deprecated
  section still run wherever you have configured them to. Rolling a custom
  monitor out to machines makes a `live` one a blocking-review stage. This is a
  separate step on the admin-only Managed Settings page. Settings-selection
  labels and checkmarks show which monitor the managed settings select for each
  stage. Gateway and Triage use managed monitors when supported by the server.
  The exception is when their grader IDs are overridden with custom monitors.
  The two stages can be overridden independently. These badges describe
  configured rollout, not observed activity on individual machines. MDM
  deployments instead show that rollout is set by MDM.

Three more are admin-only, and do not appear in the navigation otherwise:

- **Managed Settings**, the org's
  [managed client settings](organization-settings.md#managed-client-settings)
  document, and whether Watcher distributes it to machines.
- **Model Usage**, the grading spend: which models ran, how much, and what it
  cost.
- **Organization**, the org-wide [settings](organization-settings.md)
  themselves, Slack notifications included.

## Severity

Severity groups scores on Watcher's 1-10 scale into four bands:

| Band | Score |
| --- | --- |
| Low | 1-3 |
| Medium | 4-6 |
| High | 7-8 |
| Critical | 9-10 |

Session lists and dashboard Findings use the latest deep-review verdict for
the session. They do not use the highest tool-call score or the highest score
across all its graders. A session without a deep-review verdict has no severity
band. This does not mean it was judged low risk.

Tool-call rows use the gateway's decision score. When grading succeeds without
a gateway score, they use the triage score instead. Failed grading leaves the
call unscored, even if triage produced a score. **Not scored** (`not_scored` in
the API) selects calls without a usable score; it is not a fifth band.

Severity describes the assessment, not whether the call ran. Enforcement mode,
rules, thresholds, and human decisions determine that outcome. See
[Blocking and trailing review](blocking-and-trailing-review.md).

## What it is not

The Analyzer reads and configures. The Watcher client and gateway integrations
handle conversation recording and tool-call enforcement. Per-machine settings
and the client's local UI are described in [Client](../client/index.md).

The Analyzer shows sessions, tool calls, grades, graders, usage, and
organization settings. These are also available over the
[Watcher API](../api/index.md). The API is the better route for export, bulk
queries, and anything you want to run on a schedule. API-key and member
management are the exception. Those are the sign-in provider's own components.
They are not on the API.