Copy-Trade Group Health: Status, Alerts, and Recovery

Health is not the same as process uptime. A server can be running while a leader stream is stale, one follower token has expired, a queue is delayed, or an order outcome is unknown. Conversely, a group can be intentionally paused with all positions known; that is safer than showing it as failed or pretending it is active.

Compute health from several dimensions and preserve account scope. The leader dimension asks whether fill events are current and ordered. The follower dimension asks whether each account can receive and report requests. The execution dimension tracks rejects, partial fills, unknown outcomes, and queue age. The reconciliation dimension compares actual positions with current targets.

Do not use the status to promise fills or synchronization. Its job is to expose evidence and prompt an action. A green status means current checks pass within stated thresholds, not that the next broker request will be accepted or filled.

Leader freshness needs the timestamp of the last expected event or heartbeat plus sequence continuity where available. Follower connectivity needs authentication validity and a successful account-scoped capability check, not only an open socket. Processing capacity includes queue depth, oldest-item age, rate-limit responses, and worker progress.

Execution outcomes should count recent acknowledged, partial, rejected, canceled, and unknown requests by account. Reconciliation needs current orders and positions compared with the follower target. Attach data age to every measure; a position that was correct ten minutes ago cannot prove current health after a connection gap.

Each dimension has its own threshold and response. A temporary queue warning might only slow fan-out, while an unknown position after reconnect may require an immediate pause. Keep the raw measures visible beneath the summary so an operator can understand why the state changed.

A practical vocabulary is healthy, warning, degraded, paused, and unknown. Healthy means all required checks are within thresholds. Warning means operation can continue under policy but a threshold is approaching or a low-severity exception exists. Degraded means a required path is unavailable or a material exception needs containment. Paused means automation is intentionally disabled. Unknown means evidence is too stale or incomplete to classify safely.

Define precedence. For example, an intentional group pause can be displayed as paused with a nested unknown follower rather than overwritten as healthy. A material unresolved position mismatch should outrank a cosmetic alert. Avoid colors without text; operators need the state, affected scope, reason, start time, and expected next action.

Also define recovery. A follower should not return to healthy simply because its socket reconnects. Require account refresh, outstanding-order lookup, position reconciliation, and a short stable observation period. Record who or what resumed it.

Normal order lifecycles are noisy. An acknowledgement followed by a fill is telemetry, not necessarily an alert. Escalate when a state persists beyond a threshold, violates a risk boundary, or requires human choice. Examples include leader stream stale beyond tolerance, unknown follower outcome, authentication expiry, persistent partial fill, position drift, or queue age that makes intents obsolete.

Group related events into one incident keyed by group and cause. Ten followers affected by one connector outage should not page as ten unrelated mysteries. Still list each account and its last known position. Deduplicate repeated broker messages and update the existing incident as evidence changes.

Route severity by exposure. A paused follower with no position and an expired token may be a warning; an unknown long position after an exit event is urgent. Include safe links to the group view and runbook, but never include credentials or sensitive tokens in notifications.

Contain at the narrowest safe scope. Pause one follower for an account-specific reject, a connector segment for a shared authentication outage, or the entire group when leader event continuity is uncertain. Pausing must not erase monitoring of existing orders and positions.

Establish truth from the broker. Refresh open orders, recent fills, and current position with timestamps. A timeout is unknown, not rejected. If the original request succeeded, a retry could double exposure. Compare actual position with the latest target after accounting for all leader fills and policy changes.

If correction is required, calculate one explicit quantity and treat it as a new independently tracked order. Verify its broker outcome and final position. Then clear the incident only after evidence is fresh and the root cause has been addressed. Resume at reduced size or with one follower when the failure was material.

Instantaneous drift can be normal while a follower order is working. Persistent drift after a final reject or cancel is different. Display target position, actual broker position, signed difference, first-seen time, last-updated time, and any correlated working quantity.

Use tolerances carefully. A quantity tolerance of zero can still allow a short time tolerance for normal processing. A nonzero quantity tolerance may be appropriate only when the sizing policy intentionally rounds. Never hide drift simply because the group's total nets to zero; one follower long and another short are separate exposures.

Price drift is distinct from quantity drift. Followers may hold the intended quantity at different average prices because executions are independent. Track both, but do not “correct” a price difference by adding contracts. Recovery should target exposure, not cosmetically match a leader's average price.

Run controlled drills for stale leader data, follower authentication expiry, safe policy skips, partial outcomes, unknown responses, queue delay, and reconnect. Verify the expected state, alert, pause scope, and recovery checklist. Use simulation or local policy gates where possible rather than violating a broker rule to manufacture an error.

Review incidents by cause, duration, affected accounts, maximum drift, operator action, and time to verified recovery. Repeated warnings can reveal capacity or configuration problems. However, simply lengthening every threshold to suppress alerts can allow stale actions and unknown exposure to persist.

Version health rules and record the effective configuration with each event. Reassess when account count, connector mix, strategy cadence, contract month, or provider behavior changes. The goal is not a permanently green dashboard; it is fast, truthful recognition of when copying is safe to continue and when it is not.