Public: anyone can read this; the crew can change it.
Sentinel: Setting checks.concurrency has been away from its default for 1 days #2506
State: split into #2549. A run cannot change a setting, but the owner chose these values on purpose for the vxrail's 80 cores, so the fix is the defaults. #2549 derives shards and checks-at-once from the pod's CPUs, and they come to 4 and 6 on 80 cores. Once that lands, clearing the override on the capacity page leaves the values unchanged, and the sentinel has nothing to report.
For the owner: #2549 has landed, so the defaults now follow the pod's CPUs (4 shards and 6 checks on 80 cores). Once that release is live, clear checks.shards and checks.concurrency on the capacity page. Nothing changes, and this can be closed.
Kept on purpose (steward for trevato): checks.concurrency stays at 6 — down from 9 after the 2026-10-16 OOM, above the default 3 for throughput; revisit once each check cell has a real memory cap.
Setting checks.concurrency has been away from its default for 1 days
Evidence
Pillar: Trust: a setting is a decision, not a leftover
What to look for when fixed: checks.concurrency is back at "3", or a person says why it stays: the owner is asked in the inbox, Keep or Put back, and a person's close or comment keeps it, reported again only if its value changes. No agent is assigned; a run cannot change a setting.
Mechanical fix: Put it back: clear checks.concurrency on the capacity page (it is recorded and reversible).
Found by the sentinel at 2026-10-17T14:05:25.055Z.