Analyzer

The Analyzer is Watcher's web dashboard. Your deployment serves it, and it is the surface your team spends its time in: everything the Watcher client records on developer machines arrives here, graded, for a human to look at.

On Apollo's hosted cloud it is at https://app.apolloresearch.ai. On a self-hosted deployment it is your own hostname, the one your reverse proxy fronts. Whoever your deployment authenticates is who can sign in; see Organization settings for how members and admins are distinguished.

What you can do in it

The Analyzer has three areas everyone sees:

• Dashboard. The org-wide view starts with the tool calls Watcher approved without asking anyone during the selected period, beside the smaller number that needed a decision. Tools that always go to a person, such as a request for your input, sit outside both: Watcher expects those to reach you, so the total shown is those two groups rather than every call in the period. Those two blocks and the flow leaving them are drawn at different scales. A working deployment approves thousands of calls for every one it stops, so 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, and the first block reads Watcher would have auto-approved, since Watcher acts on nothing in that mode. A period can show both groups, such as when it spans a mode change. When only one group has outcomes, the flow goes directly to those outcomes.

  Select any label or flow to open the Sessions page with the same period and outcome filter applied. The auto-approved block opens the period unfiltered: the Sessions page filters on decisions, and these are the calls where there was none to make. The flow sits under Coverage, alongside 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: the Sessions to Review list, which holds sessions at or above the selected severity with recently blocked ones first; the rate and count of those sessions; and a daily trend whose 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, because how much Watcher saw and checked does not depend on what it found.

• Sessions. The queue. Every recorded session with its grades, filterable so you can start from the ones that matter rather than the newest. Opening one gives you its transcript: what the agent did, turn by turn, with the grades and the blocking review decisions shown against the tool calls that produced them.

• Monitors. The graders your organization runs, built-in and your own, and where new ones are written. Monitors is the Analyzer's name for graders. Rolling one out to machines is a separate step on the admin-only Managed Settings page.

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.

What it is not

The Analyzer reads and configures; it does not record. Recording, blocking review, and per-machine settings all happen in the client on the developer's machine, and the local UI the client serves is a separate thing from this dashboard. See Client.

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