External Status Endpoints¶
QIE serves a small set of read-only HTTP status endpoints on the management console port (-Dqie.port). An external monitoring system (Nagios, Zabbix, SolarWinds, or a scheduled script) can call them to check the engine and individual channels without signing in to the console and without an API token.
These endpoints report status only. They never start, stop, or change anything. To control a channel from an external system, use the authenticated Management API instead.
Choosing the right check
These endpoints answer "is QIE up, and is this channel healthy", the question a monitoring system asks. They are not the right choice for a load balancer or a container orchestrator, which need to know whether a QIE node instance is running and ready to receive messages. For that, use the probe port, which is purpose-built for health checks and is aware of cluster primary/failover state. In Kubernetes, point the startup, readiness, and liveness probes at the probe port. See Monitoring QIE HA Node Instances.
Engine Version and Uptime¶
/appVersion returns the running QIE version and the time the JVM started. Use it as a coarse "is the service answering" check and to confirm which build a node is on.
Response:
The version string is the full four-part version, including the build number. The response is plain text, not JSON.
Channel Status¶
/channelStatus with a channelId parameter returns a detail record for a single channel. The channel ID is shown in the Channel ID field of the Channel Properties dialog.
responseType is optional and accepts JSON or XML. JSON is returned when the parameter is omitted, and when it is set to anything other than XML.
Response:
{
"channelName": "CPSI >> GE Lab",
"channelState": "Running",
"channelStatus": "OK",
"receivedCount": 18422,
"inboundQueueCount": 0,
"inboundQueueState": "OK",
"outboundQueueCount": 0,
"outboundQueueState": "OK",
"lastMsgReceivedMillis": 1786012353000,
"lastActivityMillis": 1786012353000,
"inactivityState": "OK",
"inactivityMsg": "",
"errorQueueCount": 0,
"errorQueueState": "OK",
"lastErredMessageMillis": 0,
"completedCount": 18422,
"QIEVersion": "26.2.1",
"QIEBuild": "16531"
}
| Field | Description |
|---|---|
channelName |
The channel's configured name. |
channelState |
Running, Paused, Stopped, or Erred. |
channelStatus |
Roll-up severity across every check below: OK, WARNING, or CRITICAL. |
receivedCount |
Total messages received by the channel. |
inboundQueueCount / outboundQueueCount |
Current queue depth. |
inboundQueueState / outboundQueueState |
OK, WARNING, or CRITICAL against the configured queue thresholds. |
lastMsgReceivedMillis |
Epoch milliseconds of the last message received. |
lastActivityMillis |
Epoch milliseconds of the last channel activity. |
inactivityState / inactivityMsg |
Result of the channel's inactivity rule, and a description when it is not OK. |
errorQueueCount / errorQueueState |
Error queue depth, and CRITICAL whenever it is above zero. |
lastErredMessageMillis |
Epoch milliseconds of the last erred message. |
completedCount |
Total messages completed. |
QIEVersion / QIEBuild |
Version and build of the responding node. |
The channelStatus roll-up is CRITICAL when the channel is stopped, erred, or paused, when a queue is at its critical threshold, when the inactivity rule is critical, or when any message is sitting in the error queue. It is WARNING when a queue or the inactivity rule is at its warning threshold. Queue thresholds come from the system defaults described in Queue Alert Defaults, overridden per channel where configured.
Note
An unrecognized channel ID returns HTTP 200, not 404. The body carries channelStatus of CRITICAL and an errorMsg field describing the lookup failure, so a monitoring check should key on channelStatus rather than on the HTTP status code.
Listener Port Check¶
/channelStatus with a port parameter reports whether a channel is listening on a given port. Unlike the channelId form, this one answers with an HTTP status code and an empty body, which suits monitoring tools that only inspect the status line.
| Status | Meaning |
|---|---|
| 200 | A channel is configured on that port and its receiver is running. |
| 503 | A channel is configured on that port but is not running. |
| 404 | No channel is configured on that port. |
Only listener-style receivers occupy a port and can be found this way: HL7 MLLP, secure socket, ASTM socket, HTTP Listener, DICOM, and ISO 8583. Channels whose receiver polls instead of listening, such as File, FTP, and Database, have no port and are never matched.
Note
A paused channel returns 200. Its listener is still bound and continues to accept and queue messages, so from a load balancer's point of view the port is healthy. The channelId form reports the same channel as Paused / CRITICAL.
Legacy Plain-Text Format¶
The original form of the endpoint takes the channel ID as a bare query string with no parameter name, and answers with a single line of text.
Response:
When a queue is backed up, messages have erred, or an inactivity rule has fired, the affected counts are appended in parentheses:
The line always opens with OK, WARNING, or CRITICAL, and the parenthetical lists only the values that are non-zero. It is omitted entirely when everything is clear.
This form is retained for compatibility with existing monitoring checks. New integrations should use the channelId form above, which is structured and carries considerably more detail.
Data Freshness and Polling¶
Not every value in the response is read fresh on each call:
Read live on every request: inbound and outbound queue counts, last message received, last activity, and last erred message.
Served from the engine's cached counters: received, completed, and error counts. These are refreshed on the engine's aggregation cycle rather than per request, so they can lag by a short interval. Do not build real-time alerting on them.
Poll the channelId form no more often than every 30 to 60 seconds. Answering it takes a per-channel lock that message processing also uses, and in an HA cluster it queries outbound queue depth for each destination node. Anything that needs to check more frequently than that (a load balancer in particular) belongs on the probe port.
Fields may be added to these responses in future releases. Parse by field name and ignore fields you do not recognise.
Network Access¶
These endpoints are unauthenticated by design: the monitoring systems they were built for could not present credentials. They are served on the management console port, so they inherit the console port's network posture. The console port should be reachable only from trusted networks, and never from the public internet. See Network Layout Behind a Load Balancer for the recommended layout.
Where a monitoring host sits outside that boundary, allow it through to these specific paths at the reverse proxy or firewall rather than opening the console port itself.
Warning
/channelStatus discloses channel names, queue depths, and error counts to any caller that can reach the console port. Treat it as operational information and restrict access at the network layer accordingly.