Why are runtime states more important than status metrics?
States define what the system is permitted to do next. Metrics describe what already happened. Operators need the first to act and the second to review.
Trading Systems
How Runtime States Work: Running, Paused, and Stopped Trading Systems
Why runtime states matter in trading systems, how operators should interpret them, and what a clear product interface or dashboard should communicate.
The fastest way to lose confidence in a system is to hide its operating state. Runtime states define whether the software may evaluate inputs, submit new requests, continue monitoring, or wait for recovery. Clear labels matter, but the transition rules and operational consequences behind each label matter more.
Running is not the same as healthy
A system can be running and still need attention. Runtime state should be visible alongside event context so operators know what the software is doing.
A useful interface pairs the state with recent activity, so an operator can tell the difference between a workflow that is running normally and one that is running but stuck behind an input it never received.
Paused is a deliberate control boundary
Paused should mean the operator intentionally stopped new actions while preserving visibility and context. It is a control state, not a vague partial failure.
Pausing should also be reversible and attributable. The interface should record who paused the workflow and when, so resuming is a decision rather than a guess.
Stopped should be unambiguous
Stopped means the system is not taking new action. That state must be explicit in both the interface and the operating model.
Ambiguity here is expensive. If stopped can quietly mean partially stopped, the operating model has a gap that no amount of interface polish will close.
Design the transitions, not just the labels
Most operational confusion happens between states rather than inside them. What occurs to in-flight work when a workflow is paused? What is discarded when it is stopped? Who is allowed to resume it?
Answering those questions in the design phase is far cheaper than answering them during an incident.
- What happens to in-flight work at the moment of a pause
- Whether queued input is retained, rejected, or replayed
- Which roles may resume or stop the workflow
- How the transition is recorded for later review
What operators should answer in five seconds
A well-designed runtime surface passes a simple test: a new operator should be able to answer these questions from one screen, without asking a colleague.
- Which state is the system in right now?
- Who last changed that state, and when?
- Is anything waiting behind the current state?
- What is the next action, and who owns it?
Specify state consequences before naming controls
For each state, define whether new signals are evaluated, whether new order requests may be submitted, how open orders are handled, whether position monitoring continues, which alerts remain active, and who may transition out. Paused can mean stop new submissions while monitoring continues; stopped may require a clean shutdown and a separate recovery process. The exact policy must be visible rather than inferred from the label.
Test transitions during an open request, stale market data, broker disconnect, configuration change, and restart. If the system cannot establish current venue state, it should enter recovery or review rather than returning directly to running. These controls manage software operation; they do not remove trading risk.
| State | New submissions | Monitoring | Exit condition |
|---|---|---|---|
| Running | Permitted by configured guards | All required monitoring active | Pause, stop, fault, or guard failure |
| Paused | Blocked | Continue defined account and order checks | Cause cleared and resume guards pass |
| Recovering | Blocked | Reconcile local and venue state | Differences resolved or assigned |
| Stopped | Blocked | Retain required health and audit visibility | Explicit restart procedure |
Practical questions
Questions that often come up
Should pausing a workflow discard queued work?
That is a design decision that must be documented. The important part is that the behaviour is explicit in the interface rather than discovered during an incident.
How many runtime states should a system expose?
Few enough to be memorable and distinct. Running, paused, and stopped cover most operating needs, provided the transitions between them are clearly defined.
Continue exploring
Related projects and tutorials
Work with Sun Cluster
Planning a similar system for your organization?
Sun Cluster engineers automated trading systems with explicit runtime state, operational safeguards, and recovery paths.