--- title: Edge Server Health description: Monitor the ControlCom Edge Server in real time: live variable values, per-client diagnostics, MQTT publisher status, and host system metrics. source: https://documentation.controlcomtech.com/build/edge-server/web-interface/health --- # Edge Server Health The Health section is the operator's window into what the Edge Server is doing *right now*. Four tabs cover the live data flow, the upstream and downstream connection states, and the host process itself. > **Workflow Stage: Collect** All four pages share a common header with an **Auto-refresh** toggle and a manual **Refresh** button. They all read from local endpoints, so they work even when the cloud connection is down, which makes Health the right place to start when something looks off. ## Auto-Refresh The header above the tabs has a single auto-refresh toggle that applies to *all* Health pages at once. When enabled, the UI re-fetches Live Values, Client Diagnostics, MQTT Publisher, and System Metrics on a fixed cadence. Choose **30s**, **1m**, **2m**, **5m**, or **10m** from the interval dropdown. Click **Refresh** at any time for an immediate pull. While a fetch is in flight, the refresh icon spins and the button is disabled. > Auto-refresh is off by default. For long-running observation (commissioning a new device, watching a flaky sensor), turn it on at 30s or 1m. For ad-hoc checks, leave it off and use the manual button so you control exactly when the read happens. ## Live Values `/health/live-values` shows every variable the Edge Server is currently tracking, sourced from all clients plus internal state variables (ISVs). **Columns** * **Name**: the variable's topic property path. * **Client**: the client that produced the value (name and type), or `ISV` for internal state variables. * **Value**: the current value. * **Timestamp**: when the value was last observed locally. * **Last Published At**: when the value was last published to the cloud (blank if it has never been sent, usually because the deadband and stale rules haven't fired yet). **Filters and search** * A search box matches across name, client, and value. * Faceted filters for **Client Type** and **Client Name** let you focus on a single protocol or a single device. * **Reset** clears all filters in one click. The table is sortable on every column and paginates at 20, 50, or 100 rows per page. **When to use it** * Confirming a newly added variable is reading. * Comparing the local value against what the cloud is showing. A divergence usually means deadband filtering, a stale-after timer, or a disconnected MQTT publisher. * Spotting variables that have a recent **Timestamp** but a much older **Last Published At** (deadband holding them back). ## Client Diagnostics `/health/client-diagnostics` shows one row per configured client (Modbus TCP, Modbus RTU, OPC-UA, BACnet, LoRaWAN, MQTT, HTTP, etc.) with its connection state and protocol-specific counters. * A **green dot** marks the client as connected; **red** marks it disconnected. * Each row carries protocol-specific diagnostic fields supplied by the server: for example, last successful read time, error counts, or last error message. **When to use it** * Triaging "no data from device X": check whether the client is connected, when it was last seen, and whether the error count is climbing. * Verifying that a configuration deploy actually picked up. Disconnected clients you just added usually mean a typo in host/port or a network reachability issue (use the [Ping tool](https://documentation.controlcomtech.com/build/edge-server/web-interface/tools/ping) to confirm). ## MQTT Publisher `/health/mqtt-publisher` is a focused view of the outbound MQTT pipeline that ships data to ControlCom Connect. **Fields** * **Connection Status**: Connected (green) or Disconnected (red). * **Batches Sent**: cumulative number of batch publishes since startup. * **Items Sent**: cumulative count of individual variable updates published. * **Bytes Sent**: cumulative bytes on the wire, with B/KB/MB formatting. **When to use it** * Confirming cloud connectivity from the device side. If the publisher is Connected and Items Sent is growing, the Edge Server is shipping data successfully. * Estimating the deadband effectiveness: compare Items Sent with the variable count from Live Values over the same interval. * Detecting silent failures: a Connected publisher with a flat Items Sent counter usually means deadband and stale rules are filtering everything out, not that the device is broken. ## System Metrics `/health/system-metrics` shows resource usage for the Edge Server process itself. **Fields** * **Working Set**: resident memory (what the OS reports as in-use), in MB. * **Private Memory**: committed private memory, in MB. * **GC Total Memory**: managed heap size after the most recent GC, in MB. * **Uptime**: process uptime in seconds. * **Thread Count**: current managed thread count. **When to use it** * Verifying the container hasn't restarted recently (Uptime should be growing). Frequent restarts usually point at an OOM kill; check container logs. * Capacity planning: the minimum recommended memory is 256 MB, but a busy device with many clients and high deadband traffic can grow well beyond that. If Working Set is climbing without bound, raise it with your team. * Confirming a thread leak suspicion: a slowly increasing Thread Count over hours is a smell.