Read time … min

Observability for Automated Trading Runtimes

Understand what your trading process is doing while it runs in the cloud.

TradingHost gives automated trading projects a cloud runtime with direct visibility into the output of the running container. When your strategy, framework, connector or application writes to standard output, TradingHost captures that output and makes it visible from the control plane.

For traders moving from VPS-based execution to cloud-native runtimes, this is a simpler way to inspect application behaviour without remote desktop sessions, terminal windows or manually managed log files.

Observability surface

  • STDOUT and STDERR captured
  • Runtime container output
  • Visible from the control plane
  • Language-agnostic
  • GitHub-driven feedback loop
  • No remote desktop sessions
  • No customer-managed log files

Section 01 · Around the runtime

Built around the runtime, not the desktop

Traditional VPS-based trading often leaves observability scattered across desktop terminals, platform logs, local files, scripts and remote sessions. The tools are wherever you last left them.

TradingHost takes a different approach. Your project runs inside a managed container runtime, and the control plane gives you visibility into the output produced by that runtime. You can inspect what happened after a deployment, whether the process started correctly and what your application is reporting while it runs.

Observability stops being a separate ritual you do on a desktop. It becomes part of the trading runtime itself.

Observability, defined

On TradingHost, observability is the runtime log surface. The platform captures standard output and standard error from the running container and surfaces it from the control plane, so you can answer operational questions about your deployment without opening a server session.

Section 02 · STDOUT and STDERR

Runtime logs from STDOUT and STDERR

TradingHost starts with the standard logging interface used by containerized applications: STDOUT and STDERR. If your strategy prints something while it runs, the platform can surface it.

Startup messages, framework logs, broker connection events, exchange API errors, rejected order messages, reconnect attempts, runtime exceptions. If your application writes any of those lines to standard output or standard error, that output can be surfaced from the TradingHost control plane.

  • STDOUT

    Normal application output. Startup messages, framework logs, broker connection events, run-loop heartbeats, order submission lines and anything else your strategy prints to standard output.

  • STDERR

    Application error output. Exchange API errors, rejected order messages, authentication failures, reconnect attempts and runtime exceptions captured while the process is alive.

The same path works for every supported language and framework. Anything that can run inside a container can write runtime output that TradingHost captures.

Container-compatible

  • Python
  • Node.js
  • Go
  • Rust
  • Java
  • C#

Section 03 · What you can use it for

The questions runtime logs already answer

Six operational questions a trader asks after a deployment, and what the runtime surface tells you about each one.

QuestionWhy it matters
Did my runtime start?Confirms the deployed process actually launched.
Did my strategy enter its run loop?Confirms the application is active rather than silently exiting.
Did my broker or exchange connection succeed?Helps identify authentication, network or API issues.
Did an error occur after deployment?Makes deployment problems visible without opening a server session.
Did my application reconnect after a failure?Helps monitor long-running trading processes.
Did the latest code change behave as expected?Gives immediate feedback after a GitHub-driven deployment.

The exact visibility depends on what your application outputs. TradingHost provides the runtime log surface. Your project remains responsible for producing meaningful application-level logs.

Section 04 · GitHub-driven loop

Designed for GitHub-based deployment

Observability is most useful when it is connected to deployment. TradingHost is designed around GitHub-native workflows. You push code, deploy a project and inspect the runtime output produced by that deployment.

That gives you a clear operational loop with three checkpoints.

  • Step 1

    Code lives in GitHub

    Your strategy, framework configuration and deployment manifest sit in a GitHub repository. GitHub is the source of truth for what is meant to be running.

  • Step 2

    Deployment runs on TradingHost

    TradingHost reads the repository, builds the container and starts the runtime. The deployment is the moment the next iteration of your code becomes live.

  • Step 3

    Runtime output is visible

    Standard output and standard error from the running container surface in the control plane. You can see whether the deploy started, whether it stayed up and what it reported while it was running.

Section 05 · Brokers and frameworks

Useful for broker and exchange-connected strategies

Automated trading systems depend on external connections. A strategy may need to authenticate with an exchange, open a WebSocket stream, call a broker API, check balances, submit orders, handle rejections and recover from temporary connection failures.

TradingHost observability does not replace broker or exchange reporting. It gives you visibility into what your application reports while interacting with those systems, which is the part neither side traditionally tells you about.

Exchange runtime pages

Section 06 · AI-assisted workflows

Built for AI-assisted workflows

TradingHost observability also supports AI-assisted development. When using Cursor, Claude Code, VS Code or CLI-based agents, runtime output becomes an important feedback loop.

An agent can help modify the code. GitHub can hold the source of truth. TradingHost can run the project. The resulting logs can guide the next iteration. Each stage has a clear owner.

Where MCP fits

MCP is the control and management interface for deployment, observability and runtime operations. It is how an agent inspects a runtime or triggers a redeploy. It is not the path through which trades are executed. Order routing stays inside your strategy, against the broker or exchange your code already talks to.

Section 07 · What it isn't

Operational visibility, not performance analytics

TradingHost observability is focused on runtime operations. It helps you understand whether your deployed trading process is running, failing, reconnecting or producing expected output. It does not try to be everything else.

What the runtime log surface covers

Did the deployment start, did the strategy enter its run loop, did the broker or exchange connection succeed, did errors occur, did the application reconnect after a failure, did the latest code change behave as expected. Operational questions with operational answers.

  • It is not a backtesting engine.
  • It is not a broker.
  • It is not a strategy builder.
  • It is not a portfolio analytics platform.
  • It is not a replacement for broker statements or exchange trade history.

TradingHost is the production runtime and infrastructure layer for automated trading code. Strategy creation and backtesting belong in AlgoBuilder. Performance analytics and trader intelligence belong in TrackATrader.

Related

Part of the TradingHost platform

FAQ

Frequently asked questions

TradingHost provides visibility into runtime output from the running container, starting with STDOUT and STDERR logs. Anything your application writes to standard output or standard error can be surfaced from the control plane.

No. TradingHost observability is for runtime operations. Trade analytics, performance attribution, equity curves and portfolio intelligence belong in analytics tools such as TrackATrader.

Yes. Any language that can run inside a container and write to standard output can produce logs that TradingHost can capture. Python, Node.js, Go, Rust, Java, C# and other container-compatible languages all share the same observability path.

Your strategy should write useful operational output. If your application is silent, there will be less to inspect from the control plane. Most frameworks already log meaningful events out of the box, so for many projects the change is small or none.

Yes, where your application logs them. TradingHost surfaces the output your code produces while interacting with brokers, exchanges, frameworks and connectors. The platform does not invent errors, but it also does not hide them.

Detailed logging and implementation guidance lives in the Logs documentation. The page covers how to write structured output, how to redact sensitive values and how to organise log lines so they remain useful at scale.

On a VPS, you often have to log into the server, find the right log file, scroll through it and stitch the picture back together. On TradingHost, the runtime captures STDOUT and STDERR directly from the container and surfaces them in the control plane, so observability is part of the runtime rather than a separate desktop ritual.

No. The runtime captures standard output and standard error from the container as part of how the platform operates. You do not need to install a logging agent, configure a sidecar or run a separate log shipper to get runtime visibility.

No. TradingHost shows you what your application reports while it interacts with the broker or exchange. The authoritative record of orders, fills, balances and statements remains with the broker or exchange.

Yes. Frameworks that run inside a container and write to STDOUT or STDERR are compatible with the runtime log surface. The platform treats framework output the same way it treats application output.

See your runtime, the moment it runs.

Connect GitHub, deploy a strategy and read the runtime output as it happens. No remote desktop sessions, no managed log files, just the container telling you what it did.