Nodes in the EMQX cluster with version, uptime and resource use.

Start here when asked "is EMQX healthy", "what version is running", or before any node-specific call, to learn valid node names.

Everything EMQX knows about one node.

Live counters for the whole cluster.

Answers "how many devices are online" and "how many subscriptions exist" in one call — cheaper than listing clients.

Current throughput gauges (messages/s in and out, dropped, rate).

Time-series metrics over a recent window.

Use this to answer "was there a spike", "when did connections drop", or to correlate an incident with broker load.

Broker alarms — the first place to look when something feels wrong.

Raw Prometheus exposition text. Large — prefer emqx_broker_stats.

List MQTT clients known to the broker.

Answers "which devices are online", "is device X connected", and "who is connecting from this IP". Walk large fleets by raising page rather than limit.

Full session detail for one client: keepalive, in-flight queue, protocol, subscriptions count, connect and disconnect timestamps.

Which topics one client is subscribed to, with QoS.

Use this when a device "isn't receiving anything" — usually the subscription filter does not match the publish topic.

[DESTRUCTIVE] Disconnect an MQTT client and clear its session.

Queued and in-flight messages for that session are lost. Devices with auto-reconnect usually return within seconds, so this forces a fresh connection rather than blocking one — use emqx_ban to keep a client out.

[DESTRUCTIVE] Add a subscription to a client on its behalf.

The device does not know this happened and will not re-create the subscription after a clean-session reconnect.

[DESTRUCTIVE] Remove a subscription from a client on its behalf.

The device stops receiving that topic immediately and has no way to tell why.

Topics that currently have a route (i.e. at least one subscriber).

A topic missing here means nobody is subscribed — which is the usual reason a published message appears to vanish.

Every subscription in the cluster, with filters.

match_topic is the powerful one: given a concrete topic, it tells you exactly which subscribers would receive a message on it.

Publish a single MQTT message through the broker.

This is how you drive a device or feed a Home Assistant MQTT entity. Publishing to a topic nobody subscribes to succeeds silently — check emqx_list_subscriptions if nothing reacts.

Publish a batch of MQTT messages in one round trip.

Prefer this over many emqx_publish calls when seeding several topics — for example bringing up a set of test entities.

Retained messages the broker is holding.

Retained messages are the broker's memory of "last known value" per topic — stale ones are a common cause of ghost entities appearing after a device is removed.

Read the retained message stored for one topic.

Returns found=false when the topic has nothing retained — that is an ordinary answer, not an error.

[DESTRUCTIVE] Delete the retained message for one topic.

This is the correct way to remove a stale Home Assistant discovery entry or a ghost device state. It cannot be undone — the previous payload is gone unless something republishes it.

The authenticator chain and each authenticator's status.

Check this first when devices cannot connect: an empty chain means EMQX has no user table, so every credential is rejected.

Manage MQTT accounts in the EMQX built-in authentication database.

These are the credentials devices use to connect to the broker — not the dashboard login. If no authenticator exists yet, create one in the EMQX dashboard first; without it there is no user table to write to.

Operations enabled on this server: create, delete, read.

Authorization sources in evaluation order.

Order matters: the first source that returns allow or deny wins.

Global authorization behaviour: what happens when no rule matches, what a denial does to the connection, and cache settings.

Read and write built-in-database ACL rules that decide which topics a user or client may publish to and subscribe to.

Operations enabled on this server: create, delete, read.

Everything currently barred from connecting, with expiry times.

[DESTRUCTIVE] Block a client id, username or IP from connecting.

Unlike emqx_kick_client this persists — the target stays out until the ban expires or is lifted with emqx_unban.

[DESTRUCTIVE] Lift a ban so the client may connect again.

Packet traces defined on the broker, with status and expiry.

Start capturing MQTT packets for one client, topic or IP.

Traces are the tool for "the device connects but nothing arrives". Note the capture buffers in memory and only flushes to disk when it expires — let it run to completion before reading the log, and do not delete it early or the buffered events are lost.

Read what a trace captured.

A trace that is still running usually returns little or nothing — its events sit in an in-memory buffer until the trace expires.

[DESTRUCTIVE] Delete a trace and its captured log.

If the trace is still running, events buffered in memory are lost. Call emqx_get_trace_log first, or wait for it to expire naturally.

Listeners, their bind addresses and running state.

This is where you confirm that 1883 (MQTT), 8883 (TLS), 8083/8084 (WebSocket) are actually up before blaming a device.

Rule-engine rules, with their SQL and enabled state.

Rules are how EMQX forwards or reshapes messages without any code — for example pushing selected topics into a database or a webhook.

Match, pass and failure counters for one rule.

A rule with matched=0 is not seeing traffic — usually its FROM topic filter does not match what devices actually publish.

[DESTRUCTIVE] Switch a rule on or off.

Disabling a rule silently stops whatever pipeline depends on it — confirm which downstream system it feeds before turning it off.

Dry-run rule SQL against a sample event. Nothing is saved.

Use this to check a rule before creating it — it reports whether the event would match and what columns the rule would emit.

Data-integration connectors and their connection health.

Open-source EMQX ships HTTP and MQTT connectors; the rest are enterprise-only, so an empty list is normal on OSS.

Outbound actions (bridges) attached to rules, with their health.