Run Health Signals: The Short List Worth Watching Live

The run health signals worth watching live fall into six families: submission health, wallet state, venue state, market state, plan adherence and operator state. Each answers a different question, each has a sampling window below which it means nothing, and each carries a threshold you set yourself. A signal you have not decided an action for in advance is not a signal; it is a distraction with a chart.

That distinction is the whole framework. Most live run views fail not because they show too little but because they show a dozen readings with no stated consequence, so the operator has to invent one under pressure. Deciding the consequence first is what turns a screen into an instrument.

Signal, metric and noise

A metric is any quantity you can read. A signal is a metric you have paired with a window, a threshold and an action before the run opened. Noise is variation in a metric that does not survive its window. The same underlying number can be all three at different times, which is why the pairing matters more than the number.

The practical consequence is that a live view should be built backwards. Start from the actions available to you: observe, adjust, pause, stop, abort. For each action, ask what reading would justify it and how confident you would need to be. Anything that does not connect to an action goes on a second screen you look at afterwards, or nowhere at all.

This is unglamorous and it is the difference between a run you can defend and a run you improvised. It also has an unexpected benefit: when a metric has no action attached, you stop feeling responsible for reacting to it, and that reduces the intervention pressure that makes live windows expensive.

The six families of run health signal

The families below are organised by what they measure rather than by where they appear in an interface. In a real setup they arrive from different places, and one of the errors this framework prevents is treating readings from different sources as if they had equal authority.

The last family is the one most frequently left off a dashboard, and it belongs there. A run with a healthy submission rate and nobody awake to respond to a stop condition is not a healthy run. If you cannot render operator state on a screen, put it in the journal at every check instead.

What each family refuses to tell you

Every reading has a boundary past which it is silent, and most bad interpretations are a reading being asked a question it cannot answer. Naming the boundaries explicitly is more useful than adding more readings.

• Submission health says nothing about value. Every transaction can confirm while the run does something economically pointless. Confirmation is a statement about the chain, not about your plan.
• Wallet state says nothing about cause. A balance falling faster than its neighbours could be uneven work distribution, higher costs, or a single expensive action. The reading tells you where to look, not what you will find.
• Venue state says nothing about quality. Trading against the pool you planned for does not mean the pool is behaving as it did when you planned.
• Market state says nothing about causation. A price move during your run is not evidence that your run caused it, and treating it as evidence is how operators talk themselves into interventions.
• Plan adherence says nothing about whether the plan was good. Being on schedule against a badly sized plan is a comfortable way to be wrong.
• Operator state says nothing about competence. Somebody being awake and available is a precondition, not a qualification.

Leading readings and lagging readings

A leading reading changes before the consequence arrives; a lagging one changes after. Retry depth is leading with respect to failure rate, because attempts pile up before outcomes are recorded. Balance is lagging with respect to spend, because it reflects transactions that have already settled. Plan adherence is the most lagging reading of all, since it only moves once work has completed.

Mixing the two on the same panel without labelling them produces a specific error: the operator sees a leading reading move, waits for the lagging one to confirm it, and interprets the delay as the leading reading being wrong. It was not wrong; it was early. Label each reading on your sheet as leading or lagging and the confusion largely disappears.

Leading readings are where mid-run adjustments have leverage, precisely because there is still time to change the outcome. Lagging readings are where stop conditions belong, because a stop should fire on something that has definitely happened rather than something that might be about to.

Sampling windows: how long before it counts

No reading means anything until it has persisted long enough to be distinguishable from ordinary variation. The window is not a nicety; it is what separates a signal from a coincidence, and it has to be chosen before the run because choosing it afterwards means choosing it to fit the reading you just saw.

Illustrative arithmetic, with invented inputs, to show how short windows deceive. Suppose a run submits an action every ten seconds and you compute a failure share over a one-minute window: that window contains six attempts. A single failure moves the reading from zero to roughly sixteen percent, and two consecutive failures move it to a third, purely because the denominator is tiny. Widen the window to ten minutes and the same two failures sit inside sixty attempts, where they move the reading by about three points. Nothing about the run changed. Only the window did.

This gives a rule of thumb you can apply without any numbers from anybody else: a window must contain enough events that one event cannot move the reading past your threshold. If it cannot, either widen the window or raise the threshold, and record which you chose. Windows that are too wide have the opposite failure, arriving so late that the response has no leverage left, so the choice is a trade rather than an optimisation.

Why one health score misleads

It is tempting to fold everything into a single number and watch that. Composite scores fail during live windows for a structural reason: they average across families that have different actions attached. A score that drops because a wallet approached its floor and a score that drops because submissions stopped confirming look identical, and they require opposite responses.

Worse, composites hide the direction of a problem while it is still cheap to fix. Two readings moving in opposite directions can leave a composite flat, which is the exact case where you most want to be told something. If you keep a composite at all, keep it as a summary line under the individual families rather than as the thing you look at first.

The same objection applies to colour states. Green, amber and red are useful as a summary of a rule that has already been written, and useless as a substitute for one. If you cannot say which reading, which window and which threshold turned a tile amber, the tile is decoration.

A threshold costs you in both directions

This desk does not publish threshold values, because the correct value depends on your budget, your tolerance, your venue and your alternative uses of the same capital, none of which are visible from here. What can be described is the shape of the trade, and the shape is always the same: too tight costs you interruptions, too loose costs you exposure.

Write the threshold and the reason next to each other. Six months later the number will look arbitrary and the reason will still make sense, and the reason is what lets you adjust the number when your circumstances change.

Measuring during the run and measuring after it

Live readings and post-run measurement are different disciplines with different standards of evidence. A live reading needs to be fast, approximate and consistent, because its job is to trigger a decision within the window where the decision still has value. A post-run measurement needs to be complete and verifiable, because its job is to tell you what actually happened and to set the thresholds for the next run.

Confusing the two produces both failure modes. Operators who apply post-run rigour to live readings look at nothing until it is too late to matter; operators who treat live readings as final measurements report numbers they cannot defend. Keep the live sheet short and the post-run reconciliation thorough, and let them disagree, because the disagreement is informative.

If you are evaluating a hosted platform, its published account of how volume campaigns are measured tells you which of those two standards its numbers meet, and whether a reported figure comes from confirmed on-chain activity or from the tool's own record of its intentions. Ask that question of any reporting you did not build, including your own from a year ago.

Independent verification of individual readings is cheap and worth doing at least once per run. Confirmation semantics and fee behaviour are documented in the Solana documentation, and the program-level references at solana-program.com cover the account structures your transactions touch, which matters when you are trying to work out whether a reading reflects a token account problem or a routing one.

Readings not worth a panel

A short list of things that look like signals, cost attention, and rarely change a correct decision during the live window.

• Instantaneous rates. Anything computed over a window of seconds is mostly reporting the arrival pattern of events, not the health of the run.
• Aggregate totals with no denominator. A rising count of completed actions feels like progress and says nothing without the plan it is progressing against.
• Third-party chart views. Useful context, terrible instrument. They aggregate, they lag, and they cannot distinguish your activity from anybody else's.
• Rankings and trending positions. They move for reasons unrelated to your run and invite exactly the interventions this framework exists to prevent.
• Estimated outcomes. Any projection of where the run will end is a model of the past few minutes, and the few minutes you are in are the least representative ones.

None of these are worthless. They belong in the post-run review, where you have time to interrogate them and no ability to do damage with a hasty response.

Building the signal sheet

The output of this page is one sheet, written before the run, small enough to fit on a phone screen. Each line has five fields, and a line missing any of them is not finished.

• The reading, named precisely enough that two people would measure it the same way.
• The source it comes from, and whether that source is the tool or the chain.
• The window it is computed over, chosen so that one event cannot cross the threshold.
• The threshold, with one sentence saying why that side of the trade suits this run.
• The action it triggers, drawn from observe, adjust, pause, stop or abort, and the person allowed to take it.

Six lines is a good sheet. Twelve is a dashboard nobody reads. If a family from the table above does not earn a line for this particular run, leave it out and note that you left it out deliberately, because an absence you chose is different from an absence you overlooked.

Once the sheet exists, a subset of its lines graduates into stop conditions: rules that fire without a discussion, because the discussion already happened while you were calm. That subset, and the discipline of writing it before the run opens, is the next thing to get right.