Runner Monitoring Status: Why Your Bot Live Tabs Go Dark and How to Fix It

Your Kubernetes bot is running — you can see it in the list, the uptime counter is climbing — but every live monitoring tab shows a banner: "Live monitoring is currently unreachable. The bot may still be running." The trades feed is empty. The equity curve is blank. You have a running bot and no visibility into it.

VolatiCloud now surfaces runner connectivity status directly in the console. Every bot runner reports an observed status — AVAILABLE, UNREACHABLE, or UNKNOWN — that tells you at a glance whether the monitoring pipeline between the platform and your bots is healthy. For Kubernetes runners specifically, a new config warnings system highlights exactly which fields are missing before those gaps become invisible problems.

What "Live Monitoring" Actually Requires

A VolatiCloud bot doesn't just accumulate trade data in its SQLite database for retrieval when it stops. It streams live trade events, PnL changes, CPU and memory usage, and strategy heartbeats to the dashboard via a persistent WebSocket connection. That pipeline works when three conditions hold simultaneously:

1. The bot's Freqtrade process is running inside the runner
2. The runner can expose that process via a reachable HTTP endpoint
3. VolatiCloud's backend can proxy requests through to that endpoint

On a Docker runner, condition 2 is usually satisfied automatically — the Docker daemon is directly reachable, and there's no routing layer between VolatiCloud and the container. On a Kubernetes runner, condition 2 requires an ingress configuration that routes external requests into the cluster. Without it, every bot on that runner is effectively invisible to the monitoring system.

The new runner observed status is VolatiCloud's way of telling you which condition has broken.

The Four Runner Statuses

Opening a runner's detail page or the runners list shows one of four statuses:

Status	Meaning
AVAILABLE	Runner is healthy — monitoring is reachable for all running bots
UNREACHABLE	Runner was previously reachable but connectivity has dropped
UNKNOWN	No running bots yet — no connectivity probe has been made
UNSUPPORTED	Runner type does not support live monitoring (Local runner)

AVAILABLE is the goal for any production bot. UNKNOWN is the normal starting state — a runner transitions out of it the moment a bot starts and VolatiCloud makes its first connectivity probe. If that probe succeeds, the status becomes AVAILABLE. If it fails, it becomes UNREACHABLE.

UNREACHABLE is the status that matters most operationally. It means VolatiCloud attempted to contact the runner (or a bot on it) and failed. That failure is surfaced immediately, rather than silently returning empty live-data panels.

What Happens When a Runner Is Unreachable

The key thing to understand: your bot keeps running. The Freqtrade process executing your strategy is isolated from VolatiCloud's monitoring connection. If the monitoring link drops, trades continue, stop-losses fire, and state is persisted to the bot's SQLite database as normal. You don't lose trades because monitoring is broken.

What you lose is visibility. When a runner reports UNREACHABLE, the live monitoring tabs — Trades, Analytics, Usage, and the live equity curve — are hidden from the bot detail page. A warning banner replaces them:

"We can't reach this bot's runner right now, so live data is hidden. The bot may still be running."

This banner is a signal, not a failure mode. It's telling you that the monitoring infrastructure has a gap, while making clear that the bot's execution is unaffected. In the previous version of the dashboard, unreachable runners just showed empty monitoring panels, which looked identical to a bot that was running but had no activity — impossible to distinguish without diving into logs.

Kubernetes Config Warnings: Two Fields That Control Everything

Kubernetes runners have two optional configuration fields that most users leave blank on first setup. Both affect monitoring capability directly.

Ingress Host (Critical for Monitoring)

The ingressHost field tells VolatiCloud the hostname to use when routing requests to bots inside your cluster. Without it, bots have no external entry point — VolatiCloud can't proxy monitoring traffic through, and the runner will report UNREACHABLE the moment it tries to probe a bot.

The config warning reads: "Bots will not be externally reachable (no ingress)."

Set ingressHost to the hostname exposed by your cluster's ingress controller. If you're using a subdomain like bots.your-domain.com, bot routing uses path-based routing: https://bots.your-domain.com/bot/{botID}/. You'll also need an ingress controller deployed — nginx and traefik both work. Set ingressClass to match your controller's class name.

If you want TLS (appropriate for any production deployment), enable the ingress TLS toggle. VolatiCloud will expect a secret named {ingressHost}-tls in the bot namespace. cert-manager provisions this automatically if you have a ClusterIssuer configured; otherwise, create it manually.

Prometheus URL (For Full Resource Metrics)

The prometheusUrl field connects your runner to a Prometheus instance for detailed resource metrics. Without it, VolatiCloud falls back to cAdvisor-level data: CPU and memory are available, but network I/O and disk throughput are not.

The config warning: "Resource metrics limited to CPU/memory (no network/disk)."

This is a softer problem — monitoring still works, bots are reachable, and you get the most important metrics. But if your strategy is data-heavy (large datasets, frequent candle polling) and you want to understand whether disk I/O is a bottleneck, you need Prometheus in the loop.

For a kube-prometheus-stack deployment, the in-cluster URL follows the pattern:

http://prometheus-kube-prometheus-prometheus.monitoring.svc.cluster.local:9090

Adjust the namespace (monitoring above) to match where Prometheus is deployed in your cluster.

Fixing the Warnings in Under Two Minutes

Both warnings are cleared by editing the runner's configuration — no deletion, no bot restarts required for the configuration itself.

1. Open your runner's detail page and click Edit
2. Under Kubernetes, enter the ingressHost (e.g., bots.your-cluster-domain.com)
3. Set ingressClass to match your ingress controller (nginx, traefik, or your controller's class)
4. Optionally enable TLS if cert-manager is available
5. Enter prometheusUrl if Prometheus is deployed in the cluster
6. Save

The runner validates the new configuration and clears the warnings. The next bot that starts on that runner will pick up the ingress routing and transition the runner to AVAILABLE status on its first connectivity probe.

info

The Test Connection button in the runner edit drawer checks whether VolatiCloud can reach the Kubernetes API server — it validates your kubeconfig, namespace, and cluster-level access. Config warnings are separate: they indicate which downstream monitoring capabilities are missing even when basic cluster connectivity works.

The Diagnostic Flow: From Empty Tabs to AVAILABLE

When you're investigating a bot that's running but showing no live data, the path is now well-defined:

Step 1: Open the bot's assigned runner detail page. Check the observed status.

Step 2: If the status is UNREACHABLE or UNKNOWN, look at the config warnings. A noIngress warning means the ingress host isn't configured. A noPrometheus warning means Prometheus isn't connected.

Step 3: If there are no config warnings but the runner is still UNREACHABLE, the issue is infrastructure-level: network policies blocking traffic from VolatiCloud's backend, a misconfigured ingress controller, TLS certificate errors, or firewall rules preventing external access to the ingress host.

Step 4: After fixing configuration or infrastructure issues, restart the affected bot. VolatiCloud probes on the next status heartbeat. If the probe succeeds, the status transitions to AVAILABLE within a few seconds.

The full monitoring capabilities once the runner is healthy are covered in the bot monitoring docs — trades feed, live equity curve, resource usage, and the alert pipeline that evaluates against this same real-time data.

How Runner Status Feeds into Bot Monitoring

The observed status is part of a new monitoring field on the BotRunner GraphQL type that exposes three pieces of information:

• available — used directly as the gate for showing live monitoring tabs
• status — the four-value enum (AVAILABLE/UNREACHABLE/UNKNOWN/UNSUPPORTED)
• warnings — array of config issues with machine-readable codes

The status derivation runs on a polling cadence. If a running bot hasn't reported within a three-poll-interval window, the runner status flips to UNREACHABLE. This means a healthy runner that temporarily loses its connection to the platform will show a warning — not a permanent state, but a real-time signal.

The warnings system is non-blocking. A runner with config warnings is still usable: you can run backtests, start bots, and get partial monitoring data. The warnings are operator signals, not deployment gates. But clearing them makes the full real-time bot monitoring experience available — live trades, equity curve, and per-bot resource metrics updating in under a second.

Setting Up a Kubernetes Runner for Full Monitoring

If you're building out a Kubernetes runner from scratch and want to reach AVAILABLE status on the first bot start:

1. Create the runner with your kubeconfig, namespace, ingressHost, and ingressClass
2. Enable ingress TLS if cert-manager is in the cluster
3. Set prometheusUrl if you have a Prometheus deployment
4. Click Test Connection — this verifies cluster access before you start any bots
5. Start a bot. Watch the runner status transition from UNKNOWN to AVAILABLE
6. The live monitoring tabs will appear immediately on the bot detail page

For Docker runners, the setup is simpler — there's no ingress concept, so the runner reaches AVAILABLE status as soon as the first bot starts and the Docker daemon is reachable. See Bot Runners: Cloud vs Self-Hosted for a comparison of runner types and their monitoring capabilities.

For full Kubernetes-specific setup steps, including TLS configuration and kubeconfig format, see the Kubernetes Runner docs.

---

If you have a Kubernetes runner where monitoring tabs are dark, open the runner in the VolatiCloud console and check the config warnings — clearing the ingress and Prometheus gaps takes a few minutes and gives you full live visibility into every bot on that runner.