Measure Before You Fix
Convention: see conventions/brain-first.md — before re-deriving a diagnosis,
searchthe brain for prior incidents of the same alert. A recurring alert usually has a recorded verdict already.
Route here on any alert whose claim is temporal — "X is stale", "step timed out", "pipeline wedged", "job is slow", "N hours behind". These alerts invite an immediate structural fix (raise the timeout, split the step, reorder the pipeline). Do the measurement first. It is almost always cheaper than the fix, and it frequently invalidates it. (Routing is a harness convention, not a mechanical guarantee — the contract below is the discipline that makes it stick.)
On gbrain surfaces this covers: gbrain doctor staleness checks (e.g. sync
freshness, cycle freshness), autopilot cycle alerts, the sync stall watchdog
(reason: 'stall_timeout'), and any cron monitor built on top of them.
The rule
One stopwatch measurement of the suspect step, before any code change.
If you cannot state the measured duration of the thing you claim is slow, you do not yet know the root cause, and any fix you write is a guess wearing a…
