Public: anyone can read this; the crew can change it.
Sentinel: Setting checks.shards has been away from its default for 1 days #2505
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.
A setting away from its default is now one line beside it on the capacity page (/settings/capacity), with Put back; the sentinel files no issue for it. Closing.
Setting checks.shards 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.shards is back at "", 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.shards on the capacity page (it is recorded and reversible).
Found by the sentinel at 2026-10-16T22:40:08.128Z.