Monitoring a Trading Bot: Logs, Metrics, and Alerts

A paper process can be alive while receiving no useful observations. It can also receive observations correctly while deliberately placing no orders. Monitoring starts with the experiment's expected behavior, so it does not mistake inactivity for failure or activity for success.

Define success for this run

State the resolved instruments, callback behavior, expected observation window and stop procedure before launch. A no-order observer should show evidence of delivered data and bounded logging; an order count of zero is expected. A simulated entry-and-close fixture needs different evidence. Do not measure both against a universal orders-per-minute target.

Keep application state, worker state and data state distinct. A running badge need not prove fresh quotes. A stopped badge need not prove that cancellation finished or the worker terminated. Record the final cleanup result and retain the experiment's history, including pending or failed cleanup.

Collect enough context without exposing secrets

Use stable identifiers for the experiment, immutable strategy version and instrument. Record event time when supplied, local receipt time and the clock convention. Retain accepted configuration and a bounded sample of important observations. A correlation identifier helps link records but does not guarantee that every system retained them.

Allowlist the evidence written to logs. Avoid dumping authorization headers, credentials, private environment values, full request bodies or unrestricted exception objects. Sanitization and access controls are necessary even for research logs. Truncation should preserve a clear indication that a record is incomplete rather than manufacturing a clean error message.

Choose metrics that answer a question

Google's SRE monitoring guidance identifies latency, traffic, errors and saturation as useful service dimensions. Adapt those dimensions to the actual paper experiment instead of assuming a financial statistic is always the first or best health check.

• Data: last receipt time, missing fields, invalid prices, gaps and market identity.
• Processing: callback duration and failures, queue pressure where observable, and accepted configuration.
• Simulation: admitted requests, rejected requests, assumed fills, held quantity and the fee policy.
• Resources: active worker, bounded runtime, pending cancellation and available capacity.

A rejection count identifies a symptom, not its cause. It may reflect a risk admission, invalid input or another policy. Inspect the associated sanitized reason. Marked profit likewise does not prove settlement cash, a correct price model or safe future behavior.

Put freshness in context

Store a local observation timestamp and specify the chosen freshness condition. A quiet instrument, a disconnected feed and a closed market are different possible explanations for an old quote. The experiment may need to stop making new decisions until the state is understood, but a threshold alone cannot diagnose the cause.

The public Kalshi adapter can use REST polling when credentials are absent, while other paths use a WebSocket. Expected cadence depends on the actual path. Neither delivery method proves a complete historical book. Inspect the received fields and connection behavior before interpreting a freshness graph.

Make an alert actionable

Each proposed alert should identify the observation, owner, response and evidence needed to resolve it. Separate urgent operational failures from a research summary or an expected no-order outcome. Review noisy alerts; do not automatically delete a safety signal merely because no one acted on its last occurrence.

The existence of an alert design does not mean Banger has deployed email, pager or chat integrations. Enabling a destination, escalation or automatic action is separate work. This article does not configure a notification service or authorize automatic liquidation.

Inspect the final state

Banger's public risk checks can reject new exposure after a UTC-day mark-to-market loss threshold. They do not automatically close existing holdings or guarantee a complete shutdown. Reconcile application stop intent with worker termination, key revocation and any pending cancellation under a bounded procedure.

A useful run report includes what was expected, what was observed, which data or telemetry was absent, and whether resources stopped. Monitoring should preserve uncertainty in those answers. A chart that looks normal cannot substitute for evidence of the particular journey the experiment was meant to test.