Run Status
Every fleet or workflow run writes one record. mur job status and mur fleet status read that same record through the same derivation, so the two surfaces cannot disagree about what a run is doing.
mur job list # every run MUR has recorded
mur job status <run-id> # one run, in full
mur fleet status <fleet-name> # that fleet's most recent run
State and liveness are different questions
The most common way a status lies is by answering only one of them.
State is what the run last wrote down: running, blocked, done, failed, stopped. It is read from disk, never guessed.
Liveness is whether the process behind that state is still there. It is computed at the moment you ask and never persisted:
| Liveness | Means |
|---|---|
alive | the orchestrator process exists and its heartbeat is fresh |
STALLED | the process exists, but the heartbeat has gone quiet |
DEAD | the record says running and the process is gone |
unknown | the record was rebuilt from the channel — the heartbeat cannot be recovered |
- | the run already reached a terminal state; liveness does not apply |
A crashed orchestrator therefore reports running / DEAD the moment you ask — not running / alive until some timeout expires, and not failed while it is actually still working.
The heartbeat
A live run stamps its record on an interval. Two settings in ~/.mur/config.yaml tune it:
runs:
heartbeat_interval_secs: 10 # how often a running orchestrator stamps
heartbeat_stale_after_intervals: 3 # missed intervals before STALLED
Three intervals tolerates one lost tick plus scheduling jitter without calling a healthy run dead. Both values are rejected at load if set to 0 — a zero interval would make every healthy run report STALLED instantly — and fall back to the defaults above.
Rebuilt records say so
A run's record can be re-derived from its channel if the cached copy is lost or corrupt. Everything comes back except the heartbeat, which is the one fact the channel never carried. A rebuilt record admits this rather than guessing:
state running
liveness unknown
pid unknown (record rebuilt)
heartbeat unknown (record was rebuilt from the channel)
It does not print a stale pid as though a process were still there.
An unreadable record is reported as unreadable. A permission error or a corrupt index is an error you get to see, never silently rendered as a run that never existed.
Fleet status
mur fleet status <name> is a lookup plus the shared renderer, not a second status computation. It finds the most recent run whose record names the fleet's channel and hands it to the same code mur job status uses.
$ mur fleet status builder
run run-4f2a…
kind Fleet
label fleet run
state running
liveness alive
pid 48213
started 2026-08-17T02:14:09+00:00
heartbeat 2026-08-17T02:41:52+00:00
channel fleet-builder
If a neighbouring run's index is corrupt it is skipped with a warning, not silently — one bad record must never hide the fleet's real run, and it must never disappear without saying so either.
See also
- Fleet Loops — when a looping fleet decides it is done
- Settlement — what a single turn actually verified