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 roles for access rules.

What you can do in it

The Analyzer includes these areas:

• Dashboard. Two sections show the organization as a whole. Organization metrics contains counts and trends. It requires sessions:aggregates:read:any, supplied by the admin and org-viewer roles. Organization findings contains the Sessions to Review list. It requires sessions:findings:read:any, supplied by the admin and org-viewer roles. Dashboard is available if you can access either section. If you can access neither, it is hidden and you land on Sessions instead. Each section shows a permission notice if you lack access. It does not show personal data in its place. You can still open your own sessions from Sessions. Metric links to session and tool-call lists appear only with organization findings access. See aggregate access rules.

  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 set to always go to a person sit outside both groups, because 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 Organization metrics, with session counts and trends. These include how many sessions arrived and how many were deep reviewed.

  The severity selector filters the findings list, matching session and user counts, and highlighted trend bars. The Sessions to Review list holds sessions at or above that severity, with recently blocked ones first. The daily trend bars split sessions that met the severity from the rest of the day. Tool-call outcomes and total observed and reviewed session counts do not change with this 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 have organization-wide aggregate access. 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 you may read, 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. The LiteLLM example derives a gateway ID from its required conversation header or native Claude/Codex metadata, so both forms show Gateway. 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 shows its findings. With content access, it also shows the session summary and transcript, with blocking review decisions beside tool calls. Without content access, the findings remain visible but summaries and transcript evidence are unavailable.

• Tool calls. The same decisions as rows of their own. One row per tool call Watcher recorded a blocking-review decision about, across sessions you may read. 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.

• My access requests. Your requests to view session content, newest first, with their status, raised and reviewed dates, and expiry. Expired approvals are labelled Expired. This page shows only your requests, including if you are an admin.

  On a restricted session page, select Request access. The button shows Request pending while awaiting review. An active approval replaces the button with a temporary-access banner showing its expiry. Ordinary access through ownership or a role does not show this banner.

• Access requests, with Pending, Active, and Historical tabs. Requires sessions:access-requests:review, included in the admin role and assignable to custom WorkOS roles. Historical requests are denied, revoked, or expired. Select Approve to grant eight hours of access immediately, or Deny. Reviewers may approve their own requests; every decision records who reviewed it and when. Select Revoke on an active request to end its access immediately.

Organization-settings pages include:

• 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 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.