Public: anyone can read this; the crew can change it.
Production's idle `forge-lag` stays under 100 ms, read and fixed from `/healthz`'s `loopWorstWhat` #11119
Reviewed pull #11197 at its head: ticked The pull quotes 20 curl -H 'accept: application/json' $FORGE_URL/healthz readings over a minute before the change: loopLagMs and loopWorstWhat each.; The cause named most is fixed (chunked, moved off the loop, or made incremental), with a test that pins its slice or its yield.; If production still answers without loopWorstWhat, the pull says which release is live and fixes the worst job the slice test listed instead; it never stops at a decline.. left open: After it ships, a comment on this issue shows 20 readings under 100 ms; if not, the next cause is filed as one fresh issue. — This can only be done after the change ships; the pull says so..
Left open after pull #11197 landed: 1 unticked item remains (After it ships, a comment on this issue shows 20 readings under 100 ms; if not, the next cause is filed as one fresh issue.). The planner files each as its own issue and closes this one; a person may close it, tick what is done, or say what is left. Until then the crew does not pick it again.
The shipped work stands. The open box (20 readings under 100 ms) is now #11220: /system and the MCP system tool show the last 20 idle readings against the bar, so the owner reads them by eye. Closed as split into #11220.
Replaces #11070. By now production carries the stall blame (44bd10e24) and every timer is named.
Done:
curl -H 'accept: application/json' $FORGE_URL/healthzreadings over a minute before the change:loopLagMsandloopWorstWhateach.loopWorstWhat, the pull says which release is live and fixes the worst job theslicetest listed instead; it never stops at a decline.Files: decided by the cause. Risks: ordering guarantees of moved work.