Typical problems and solutions

Provider or Detector won't start

• Check infrastructure: Redis (and QuestDB if you use it) must be running and reachable. Start infrastructure first (e.g. docker compose -f docker-compose-infra.yml up -d or the equivalent in your repo), then the app layer. See Installing and running the Provider and Docker Compose for Provider.
• Environment variables: In .env set REDIS_HOST, REDIS_PORT (in Docker often REDIS_HOST=redis). For Provider set ports, image, and if needed exchange keys (BINANCE_API_KEY, BINANCE_API_SECRET).
• Config files: Ensure config.provider.json, config.detector.json, etc. exist and are correct in your deployment config directory.
• Logs: Run docker logs -f provider, docker logs -f detector and look for connection errors to Redis, the exchange, or QuestDB. Often the cause is wrong host/port or the container not being on the same network (e.g. barfinex-network). See Understanding Provider logs.

No data in Studio

• WebSocket: Real-time data comes through Provider /ws. Ensure Studio connects to the correct URL (e.g. wss://<provider-host>/ws) and that CORS/HTTPS are configured (CORS_ORIGINS). See Building with the API.
• Redis and WS bridge: The Provider subscribes to Redis channels and forwards them over WebSocket. If Redis is unreachable or the Provider didn’t subscribe, Studio won’t get events. Check Provider logs for Redis errors.
• Proxy: If Studio talks to Advisor/Inspector/Detector via the Provider, ensure those apps are registered in the App Registry (heartbeat) and that Provider has ADVISOR_API_URL, INSPECTOR_API_URL, DETECTOR_API_URL and the matching *_APP_KEY set. See Architecture.

Mixed content errors

If Studio is opened over HTTPS but the API is called over HTTP, the browser will block mixed content. Fix: serve the API (or a reverse proxy in front of it) over HTTPS and use a single origin. See Local certificates setup and your deployment’s SSL configuration.

No signals in Telegram

• Variables: Set TELEGRAM_BOT_TOKEN, TELEGRAM_CHAT_ID. For the Detector separately: DETECTOR_TELEGRAM_ENABLED, DETECTOR_TELEGRAM_CHAT_ID, and if needed DETECTOR_TELEGRAM_MIN_INTERVAL_MS, DETECTOR_TELEGRAM_DEDUP_WINDOW_MS. See Telegram notifications.
• Logic: Telegram signals come from the Detector (and optionally Inspector). Ensure the Detector is producing events: connected to Redis, receiving data from the Provider, strategy/plugin enabled. Check Detector and Inspector logs.

Redis and Docker network issues

• Connection: All apps must use the same REDIS_HOST and REDIS_PORT. In Docker Compose, services should be on the same network (barfinex-network), and the Redis service name should match REDIS_HOST (e.g. redis).
• Test Redis: docker exec -it redis redis-cli PING should return PONG. From an app container, ensure REDIS_HOST resolves (e.g. redis on the same network).
• Timeouts and disconnects: On an unstable network you can tune reconnection (e.g. REDIS_KEEP_ALIVE_MS, REDIS_CONNECT_TIMEOUT_MS, REDIS_RECONNECT_* in the provider-ws-bridge). Provider/Detector/Advisor/Inspector logs will show Redis reconnection warnings.

QuestDB: vm.max_map_count warnings

On Linux, running QuestDB may require raising vm.max_map_count on the host (e.g. sysctl -w vm.max_map_count=262144). On Windows with WSL, your infra script (e.g. run-infra.ps1) may set this before starting. See QuestDB docs and your repo’s scripts.

Detector in read-only mode

If the Detector doesn’t open or close positions, check DETECTOR_READONLY. With DETECTOR_READONLY=true the detector deliberately does not execute orders (logging only). Set to false or unset for live execution.

Related documentation

• Installing and running the Provider — setup and launch
• Docker Compose for Provider — services and variables
• Understanding Provider logs — reading logs
• Installing the Detector — connecting the Detector
• Terminal configuration and Registering Provider in Studio
• Architecture — data flow and app registry
• Building with the API — single gateway and WebSocket
• Telegram notifications — bot and chat_id setup