> ## Documentation Index > Fetch the complete documentation index at: /llms.txt > Use this file to discover all available pages before exploring further. # Gateway Health Checks > Verify a Livepeer gateway is alive and routing jobs - health endpoints, status commands, deposit checks, and orchestrator reachability for Video, AI, and Dual gateways. This is the first of five monitoring guides. Run these checks after starting a gateway, after any configuration change, or when something seems wrong. Health checks are quick - for full observability setup, see [Monitoring Setup](/v2/gateways/guides/monitoring-and-tooling/monitoring-setup.md). ## Universal Checks VideoAIDual These checks run on all Gateway operational and node mode configurations. ### HTTP health endpoint Confirms the gateway process is running and responding on the configured `-httpAddr` port (*default: 8935*). ```bash icon="terminal" Check Command theme={null} curl http://localhost:8935/health ``` A healthy gateway returns HTTP `200` with a JSON body. Any non-200 response or connection refused means the process is not running or the port is wrong. ```json icon="terminal" Expected Response theme={null} { "status": "OK" } ``` ### Node status via livepeer\_cli Confirms the gateway's identity, network connection, active sessions, and (for on-chain gateways) deposit and reserve balances. * Select **Option 1: Get node status** from the interactive menu. ```bash icon="terminal" CLI Command theme={null} # Standard (binary on host) livepeer_cli -host 127.0.0.1 -http 5935 # Docker container docker exec -it livepeer_cli -host -http 5935 ``` The status output appears under **BROADCASTER STATS** (the CLI uses the legacy term "Broadcaster" for Gateway). ### Hardware status Confirms GPU availability, memory usage, and temperature. Useful for AI and Dual gateways where GPU resources are shared. ```bash icon="terminal" Check Command theme={null} # GPU utilisation, memory, temperature curl http://localhost:8935/hardware/stats # GPU model and system info curl http://localhost:8935/hardware/info ``` ## Node Type Checks > [tab] Video > > **On-chain** only > > A Video gateway is healthy when: > > 1. `/health` returns 200 > 2. ETH deposit is non-zero (see On-chain Checks below) > 3. At least one Orchestrator is reachable > 4. Arbitrum RPC is responding (see On-chain Checks below) > > ### Check Orchestrator connectivity > > On-chain video gateways discover Orchestrators automatically via the protocol. Verify connected Orchestrators via `livepeer_cli` (Option 1) or the HTTP API: > > ```bash icon="terminal" Check Orchestrators theme={null} > curl http://localhost:5935/getOrchestrators > ``` > > An empty array means no Orchestrators are connected. Check the Arbitrum RPC (see on-chain tab) and verify the gateway is registered on the network. > > ### Test RTMP ingest > > Push a test stream to the RTMP port (*default: 1935*): > > ```bash icon="terminal" Check RTMP theme={null} > ffmpeg -re -f lavfi -i testsrc=size=1280x720:rate=30 \ > -c:v libx264 -preset ultrafast \ > -f flv rtmp://localhost:1935/live/test > ``` > > If the gateway is healthy, transcoding activity appears in the logs (`-v 6` for verbose). If the stream immediately drops, check the deposit balance (see on-chain tab) and Orchestrator connectivity above. > [tab] AI > > **Off-chain** or **On-chain** > > An AI gateway is healthy when: > > 1. `/health` returns 200 > 2. At least one Orchestrator in `-orchAddr` is reachable (off-chain) or discoverable via protocol (on-chain) > 3. A test job succeeds end-to-end > > ### Check Orchestrator Reachability > > For off-chain gateways, verify each Orchestrator in the `-orchAddr` list is responding: > > ```bash icon="terminal" Check Orchestrators theme={null} > curl https://:/getOrchestratorInfo > ``` > > If an Orchestrator is unreachable, jobs silently fail to route. Replace addresses in `-orchAddr` with known-active AI Orchestrators. Ask in [Discord #local-gateways](https://discord.gg/livepeer) for current addresses. > > ### Run a test job > > ```bash icon="terminal" Run Test Job theme={null} > curl -X POST http://localhost:8935/text-to-image \ > -H "Content-Type: application/json" \ > -d '{ > "model_id": "ByteDance/SDXL-Lightning", > "prompt": "a simple geometric test pattern", > "width": 512, > "height": 512, > "num_images_per_prompt": 1 > }' > ``` > > A successful response returns a base64-encoded image. An error typically means either the Orchestrator does not have this model loaded or `-orchAddr` is misconfigured. > > > [!NOTE] > > > > On-chain AI gateways using `-aiServiceRegistry` discover Orchestrators automatically and do not need `-orchAddr`. Run the on-chain checks below in addition to the test job. > [tab] Dual > > **On-chain** (video component requires on-chain) > > A Dual gateway runs both video and AI workloads on the same port. It is healthy when all video checks AND all AI checks pass. > > ### Verify both workload types > > Both video and AI endpoints respond on the same port (8935): > > ```bash icon="terminal" Check Response theme={null} > # Health endpoint (covers both workloads) > curl http://localhost:8935/health > > # Test video: push RTMP stream > ffmpeg -re -f lavfi -i testsrc=size=1280x720:rate=30 \ > -c:v libx264 -preset ultrafast \ > -f flv rtmp://localhost:1935/live/test > > # Test AI: send inference request > curl -X POST http://localhost:8935/text-to-image \ > -H "Content-Type: application/json" \ > -d '{"model_id": "ByteDance/SDXL-Lightning", "prompt": "test", "width": 512, "height": 512}' > ``` > > ### Check hardware under load > > ```bash icon="terminal" Check Hardware theme={null} > curl http://localhost:8935/hardware/stats > ``` > > Watch for: > > * `gpu_memory_used` approaching `gpu_memory_total` - model loading fails when GPU VRAM is full > > * High GPU utilisation when no jobs are running - indicates a stuck process > > > [!TIP] > > > > When both video and AI workloads are active simultaneously, memory pressure is the most common cause of degraded performance. > > \ > > \ > > If GPU memory exhaustion is consistent, consider splitting video and AI onto separate nodes. > > \ > > See [Scaling](/v2/gateways/guides/advanced-operations/scaling.md). > [tab] On-chain > > Video AI Dual > > These checks apply to any gateway running in **on-chain** operational mode, regardless of node type. > > ### Check ETH deposit and reserve > > ```bash icon="terminal" Check ETH Balance theme={null} > livepeer_cli -host 127.0.0.1 -http 5935 > # Select Option 1: Get node status > ``` > > Look for the **BROADCASTER STATS** section (the CLI uses the legacy term "Broadcaster" for Gateway): > > * `Deposit` - must be non-zero (the gateway cannot issue PM tickets without a deposit) > > * `Reserve` - must be non-zero (required for ticket redemption) > > > [!WARNING] > > > > Monitor the balance proactively. > > When the deposit reaches zero, the gateway stops routing jobs with > > \ > > ***no error*** shown to the client. > > \ > > \ > > Community-recommended minimum for testing: **0.1 ETH total** (approximately 0.07 ETH deposit + 0.03 ETH reserve). > > If the deposit shows zero after bridging ETH, see [Funding Guide](/v2/gateways/guides/payments-and-pricing/funding-guide.md) - bridging does not automatically allocate funds to the TicketBroker contract. > > ### Test Arbitrum RPC > > ```bash icon="terminal" Test RPC theme={null} > curl -X POST \ > -H "Content-Type: application/json" \ > -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' > ``` > > A working RPC returns a JSON response with a hex block number. If the request times out or returns an error, the RPC is rate-limited or unavailable. See [Troubleshooting - Arbitrum RPC failures](/v2/gateways/guides/monitoring-and-tooling/troubleshooting.md#arbitrum-rpc-connection-failing). ## Automation Health Checks can be automated and notify operators of issues. ### Cron Script Automation ```bash icon="terminal" Cron Script Automation theme={null} #!/usr/bin/env bash # gateway-health.sh - run every 5 minutes via cron GATEWAY_PORT="${1:-8935}" ALERT_EMAIL="ops@example.com" if ! curl --silent --fail --max-time 5 http://localhost:${GATEWAY_PORT}/health > /dev/null 2>&1; then echo "Gateway on port ${GATEWAY_PORT} is not responding" | \ mail -s "ALERT: Livepeer Gateway Down" "$ALERT_EMAIL" fi ``` ```bash icon="terminal" Add to crontab theme={null} # Add to crontab */5 * * * * /path/to/gateway-health.sh 8935 ``` ### Docker HEALTHCHECK Automation ```dockerfile icon="docker" HEALTHCHECK theme={null} HEALTHCHECK --interval=30s --timeout=10s --retries=3 \ CMD curl --silent --fail http://localhost:8935/health || exit 1 ``` For full observability with time-series metrics, alerting, and dashboards, see [Monitoring Setup](/v2/gateways/guides/monitoring-and-tooling/monitoring-setup.md). ## Related Pages > [card] [Tools & Dashboards](/v2/gateways/guides/monitoring-and-tooling/tools-and-dashboards.md) > > Explorer, Livepeer Tools, livepeer\_cli for visual monitoring. > [card] [Monitoring Setup](/v2/gateways/guides/monitoring-and-tooling/monitoring-setup.md) > > Prometheus + Grafana for production observability. > [card] [Troubleshooting](/v2/gateways/guides/monitoring-and-tooling/troubleshooting.md) > > Fix common errors by symptom. {/* PURPOSE: Journey step: "Is my gateway alive?" Quick verification guide - the FIRST thing an operator checks after setup or when something seems wrong. Covers all 3 gateway types with different checks per type. This is not deep monitoring (that's monitoring-setup.mdx) - this is "can I confirm it's working right now?" SECTION HOME: Guides > Monitoring & Tooling JOURNEY POSITION: 1. Gateway Health Checks (this page) - "Is it alive?" 2. Tools & Dashboards - "Where do I see what's happening?" 3. Monitoring Setup - "How do I set up proper observability?" 4. On-Chain Debugging - "What's happening at the contract layer?" 5. Troubleshooting - "Something broke" RELATED FILES (draw from): - all-resources/v2-refs--health-api.mdx - OpenAPI ref for GET /health - all-resources/v2-refs--ai-health-api.mdx - OpenAPI ref for AI GET /health - all-resources/v2-refs--status-api.mdx - OpenAPI ref for GET /status - all-resources/v2-refs--hardware-stats-api.mdx - OpenAPI ref for GET /hardware/stats - all-resources/v2-refs--hardware-info-api.mdx - OpenAPI ref for GET /hardware/info - all-resources/v2-monitor--monitor-and-optimise.mdx - Brainstorm page with request flow diagram - all-resources/v2-refs--cli-commands.mdx - CLI commands reference (livepeer_cli status) - all-resources/ctx-gwnew--GW-03-faq-completed.md - FAQ: "How do I check my ETH deposit and reserve balance?" - all-resources/v1--troubleshoot.mdx - V1 troubleshoot: common verification patterns CROSS-REFS: - Payments & Pricing > Funding Guide (deposit/reserve check) - Resources > API Reference (full endpoint docs) - Troubleshooting (this section) - if health check fails, go here */} This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.