[DavidCockerill]

⊙ Problem

Staff can stop paging for a cluster by setting its monitoring policy to notify, but must hand-write a central manager request. Nothing shows which clusters are on notify, who set them, or why.

🤔 Is a Studio page warranted, rather than the API alone?

Yes: the fleet-wide list of notify clusters and their history need a page, and the main caller is support, who should not have to hand-write the request. The page is additive; removing it is one route.

💡 Solution

A Monitoring page in admin (/admin/monitoring) uses the central manager's /Admin/ClusterMonitoringPolicy (HarperFast/central-manager#984):

• Lists the clusters on notify: reason, who set it and when, and whether their synthetic checks reflect the change. It polls while a change is pending.
• Set policy finds a cluster by name or clu-… id, then sets page or notify with a required reason and an apply mode. The result shows what the save did, including a refused restart.
• History shows each cluster's changes, newest first.
• Deploy it after HarperFast/central-manager#984: until then the page's requests 404.

⚖️ Alternatives

• List only, with writes left to the API: support is the main caller, and the search and confirm step is what makes the change safe to make quickly.
• Central manager reports check status explicitly: Studio infers it from row timestamps instead; moving it server-side later is cheap here.

🤔 Offer the rolling restart from this dialog?

Yes, only to accounts that may restart the cluster, warned as undrained and off-peak. Without it, metric and log alerts follow only at each container's next recreate. Dropping the option is a one-line change.

🔧 Changes

The notify list: each badge says whether that cluster's synthetic checks carry its latest change (seeded scratch data, 1440px).

Set policy after picking a cluster from search: the other policy is preselected and a reason is required.

Product and architecture tour

Product and architecture tour

Setting a policy

What does a support engineer do to take a cluster off paging, and what can stop them?

From the rail to the result

1. Open Admin → Monitoring — every staff role that can read clusters sees the list; only monitoringPolicy:write sees Set policy and Change.
2. Find the cluster — by name or clu-… id; each match shows its organization, status and current policy.
3. Choose — the other policy is preselected, a reason is required, and the rolling restart is offered only to an account that may restart that cluster.
4. Save — the dialog cannot be closed and no second save can start until the answer arrives.
5. Read the result — instances updated, any failed instance, and a refused restart.

The page never claims more than the central manager confirmed: a failed list read says so, and "Rolling restart started" appears only when the answer carries a restart.

Did the checks take the change

How does the list know whether a cluster's synthetic checks carry its latest policy?

The central manager re-stamps a cluster's synthetic checks in the background and records the outcome on the row. The Checks badge reads it, counting only an attempt that finished after the change and projected it (a skip, which keeps the old projected change, counts by its finish time), because the row keeps the previous attempt's outcome until the new one finishes. While a change is pending the list polls every 30 seconds; after 20 minutes, past the central manager's own retries, the badge reads Not confirmed and polling stops.

Before	After
Whether a change reached the checks meant reading checkProjection from a raw API response.	Applied, Updating, Not stamped (with the gate), Errors (with the failed checks), or Not confirmed.

Every file

• src/features/admin/monitoring/index.tsx: the page. Write buttons wait for an in-flight save, a failed read shows as one, the check badge, and history newest first.
• src/features/admin/monitoring/SetPolicyDialog.tsx: the dialog stays open while saving; cluster search; the form's restart rights, required reason and disabled rolling option; and the result.
• src/features/admin/monitoring/checkStatus.ts: pending until an attempt finishes after the change, and only its own change's outcome.
• src/features/admin/monitoring/monitoringPolicyApi.ts: the hand-typed contract and queries; polling stops once stuck; the save's key; search; and every save refetches.
• src/features/admin/routes.ts, AdminShell.tsx and api.patch.d.ts: the route, the rail item on cluster:read, and the monitoringPolicy:write permission type.

✅ Verification

• pnpm test (all 571 files), pnpm lint, pnpm format, tsc -b: pass. One unrelated Monaco test (setValueHistory.test.ts) times out intermittently under full-suite load and passes alone.
• Live: this branch against a scratch central manager running HarperFast/central-manager#984, signed in as a support account. Listed two notify clusters, searched "prod", set page with apply: rolling, and saw the refused restart in the result while the list refetched.

What the new tests prove

• src/features/admin/monitoring/index.test.tsx: list and check status, history order, read-only without the write permission, trimmed search, required reason, rolling offered only with restart rights for the cluster's organization, a refused restart shown, a failed list never read as "every cluster pages", and Escape, Cancel, Change cluster and the page's Set policy button blocked while a save is in flight.
• src/features/admin/monitoring/checkStatus.test.ts: an attempt counts only once it finished after the change and, unless it was a skip, projected that change; errors only for the change they were for; stuck after 20 minutes.
• src/features/admin/monitoring/monitoringPolicyApi.test.ts: polls only while a change is pending and not yet stuck.
• adminRoutes.test.ts and adminShellVisibility.test.ts: the route resolves, and the rail item shows for every role that can read clusters.

_{🤖 Generated by Claude Code (Claude Opus 5.5); posted via @DavidCockerill.}

Refs #1986

Related PRs: #1975 overlaps (merged first; this branch is rebased on it and keeps both rail items, routes and visibility expectations)
Complexity: medium

_{Review-Coverage: authored=claude; ran=gemini,codex; adjudicated=domain; blocked=cursor-grok(lost); declined=cursor-composer,cursor-kimi,cursor-muse,muse; rounds=3; full=1 @ a8c55c7}

_{Review-Attention: read ~8m (decisions: do-less-alternative, in-flight-guard-scope, check-status-inferred-client-side, monitoring-gated-on-cluster-read, rolling-restart-from-policy-dialog) @ a8c55c7}

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	80.17%	15133 / 18874
🔵	Statements	80.11%	16069 / 20057
🔵	Functions	75.67%	4073 / 5382
🔵	Branches	74.81%	11805 / 15779

File Coverage

File	Stmts	Branches	Functions	Lines	Uncovered Lines
Changed Files
src/features/admin/routes.ts	69.23%	100%	55.55%	69.23%	33-34, 40-41, 47-48, 54-55
src/features/admin/components/AdminShell.tsx	29.41%	46.66%	60%	33.33%	43-65
src/features/admin/monitoring/SetPolicyDialog.tsx	94.59%	85.24%	87.5%	94.59%	69, 181
src/features/admin/monitoring/checkStatus.ts	100%	100%	100%	100%
src/features/admin/monitoring/index.tsx	79.41%	64%	80.95%	78.78%	82-85, 166, 174-188, 209
src/features/admin/monitoring/monitoringPolicyApi.ts	100%	100%	100%	100%

Generated in workflow #2409 for commit a8c55c7 by the Vitest Coverage Report Action

[dawsontoth]

We will want to integrate this more into the existing search and navigation among clusters with staff only features. Plus, we are getting too deep into Studio PRs that require CM PRs to merge. We need to start knocking those out.