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 or gateway hooks.

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 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 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 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 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 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 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 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 keeps its outcome, the person, and the time. It says nothing about the tool.

• Monitors. Managed monitor 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 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 stage. async means it only grades after the fact. The section is marked deprecated. For organization policy on managed live monitors, prefer custom instructions. 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 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 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.

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.

The Analyzer shows sessions, tool calls, grades, graders, usage, and organization settings. These are also available over the Watcher API. 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.