Know Which Device Went Quiet, Not Just Whether the Broker Is Up
Fivenines subscribes to your MQTT broker from an agent inside your network and watches individual topics: one for silence past a timeout you set, one for a payload that stopped saying what it should. A sensor that died last week does not get to look alive because the broker still replays its last retained message.
Built for teams monitoring production infrastructure
No credit card · 2-minute setup
MQTT topics
-
Silence Is the Signal
Set a freshness timeout per topic - anywhere from 5 seconds to 7 days - and get one alert when a device stops publishing. This is the check an IoT fleet actually needs, and the one a broker uptime probe cannot give you.
-
Retained Is Never Fresh
Freshness is measured only from live deliveries with the retain flag clear, exactly as MQTT 3.1.1 defines it. A dead device with a retained payload reads as dead, which is the whole point of watching it.
-
Your Broker Stays Private
The subscription is held by an agent you already run, so a Mosquitto on a LAN or inside a VPC needs no public address, no port forward and no inbound rule. Credentials are encrypted at rest and sent only to the agent you name.
Deep dive
Why a Retained Message Is Not a Heartbeat
MQTT brokers keep the last message published to a topic with the retain flag set, and replay it to every new subscriber the moment it connects. That is a useful protocol feature - a dashboard opening at 3am learns the current state without waiting for the next publish - and it is also a trap for anything that measures freshness.
The trap is simple. A checker that connects, receives the replayed message and records "last message: just now" will report a healthy device. It will keep reporting a healthy device every time it reconnects, indefinitely, for a sensor whose battery died a month ago. The one failure you bought the tool for is the one it cannot see.
Fivenines tracks the last live delivery separately from the last message of any kind. A message only counts toward freshness if it arrived on an established subscription with the retain flag clear - the distinction MQTT 3.1.1 draws in MQTT-3.3.1-8 and MQTT-3.3.1-9. So a topic that has only ever produced a retained replay has no live timestamp at all, and goes stale on schedule.
Retained messages are not discarded, though, because for the other kind of check they are the truth. A broker publishes a device's last-will message on its behalf when the connection drops, and that message is usually retained. It is a real statement that the device is gone, so payload expectations read retained messages as authoritative.
What You Can Watch
Freshness timeout
This topic must publish at least every N seconds, from 5 seconds up to 7 days. Past that, one alert per topic. Useful anywhere a device is supposed to report on a cadence: telemetry, heartbeats, meter readings.
Exact payload
The last message must equal a value. The standard use is a status or last-will topic that should read online, so you hear about it the moment the broker publishes offline on the device's behalf.
Payload contains
The last message must contain a substring. For firmware that reports a compound status line rather than a single token, or where you care about one word inside a longer message.
JSON key
Pull one field out of a JSON payload and compare it, including a dotted path such as battery.level or status.state for a nested object. Most modern firmware publishes JSON, so this is usually the one you want.
Wildcards across a fleet
A monitor takes a topic filter, so the single-level + and multi-level # wildcards behave as they do in any MQTT client. One monitor on sensors/+/temperature covers every sensor that matches, and each concrete topic it discovers is tracked and alerted on separately.
The broker itself
Connection state, how many topics are being watched, and how many of them are currently stale - charted per broker, so you can see a fleet going quiet as a shape rather than as a pile of individual alerts.
Deep dive
What Happens When the Broker Goes Down
Losing the subscription is not evidence about any device, and Fivenines refuses to treat it as such. If a broker restart made every watched topic look silent at once, one blip would page you for your entire fleet - and the alert you actually wanted, the broker is unreachable, would be buried under a hundred device alerts that all say the same thing.
So a lost or unhealthy subscription is treated as lost visibility. The per-topic alerts go quiet, and a separate broker alert fires and owns the outage. One incident, for the thing that is actually wrong. When the subscription comes back, the per-topic checks resume.
The same reasoning runs the other way at startup. A freshness alarm only arms once its own subscription has been healthy for its own timeout, because Fivenines will not claim a device was silent during a window it was not watching. There is one deliberate exception, and it covers the case people hit first: point a monitor at a single named topic, and if that topic produces nothing at all for the whole arming window, it fires. A device that was already dead when you set the check up has no history to go stale, so a tool that only evaluates topics it has heard from would stay silent about it forever.
From Broker to First Alert
Step 1
Add the broker
Host, port, TLS on or off, and a username and password if it needs them. Then pick which of your instances subscribes to it - any agent that can reach the broker will do, on Linux, Windows or macOS. Credentials are encrypted at rest and only ever sent to that one agent.
Step 2
Add topic monitors
Give each one a topic or a wildcard filter, then a freshness timeout, a payload expectation, or both. Watched topics and their last payloads appear on the broker page as the agent sees them, so you can confirm you are matching what you think you are matching.
Step 3
Turn on the alerts
Three one-click workflow templates cover it: a silent device, a payload mismatch, and an unreachable broker. Add them from the workflow gallery, route them to your channels, and layer on the same rechecks, escalation gates and maintenance windows as any other alert.
Deep dive
Three Alerts, and They Know About Each Other
A watched topic went silent. Fires per concrete topic, so a wildcard monitor covering forty sensors opens an incident for the one that stopped, named after the topic, and closes it on its own when a live message arrives.
A payload stopped matching. Fires while the last message fails the expectation you set, and resolves when it matches again. On a last-will topic this is how you hear that a device disconnected, in the seconds it takes the broker to publish on its behalf.
The broker is unreachable. Fires while the agent cannot hold a healthy subscription, or has stopped reporting on the broker at all. It distinguishes a connection that failed from one your credentials or TLS settings rejected, because those are different jobs: one is an outage, the other is a two-field fix in settings.
All three route wherever your team already works: email, Slack, Microsoft Teams, Telegram, Discord, Pushover, PagerDuty or webhooks. Which of those you can use depends on your plan - email, Telegram and Discord are on every plan, and the rest unlock as you move up.
Who This Is For
IoT and sensor fleets
Hundreds of devices publishing telemetry on a cadence. One wildcard monitor covers a whole class of sensor, and you find out which unit stopped reporting rather than that the average went flat.
Industrial and building telemetry
Gateways bridging Modbus, BACnet or a PLC onto MQTT. The gateway going quiet is the failure that hides everything downstream, and a freshness timeout on its topics is the cheapest way to catch it.
Home and facility automation
Zigbee and Z-Wave bridges, energy meters, environmental sensors. A payload expectation on each device's status topic turns the last-will message the broker already publishes into an alert you actually receive.
How It Compares
| Approach | Setup | Private Broker | Per-Topic Silence | Retained Aware | Alerting |
|---|---|---|---|---|---|
| TCP check on port 1883 | Minutes | Needs exposure | Broker only | No topics read | Broker only |
| Prometheus + MQTT exporter | 1-2 hours | Runs alongside | PromQL rules | Exporter-dependent | Manual rules |
| Custom script or flow | You build it | Runs alongside | You build it | You build it | You build it |
| Fivenines | 2 min | Agent-side | Per topic | Supported | 3 templates |
Included on every plan
Brokers are free. Each topic monitor counts as one monitor against your plan's limit, the same as a server or an uptime check - so a hundred sensors behind one wildcard filter is one monitor, not a hundred.
Frequently Asked Questions
How does Fivenines connect to my MQTT broker? +
Will a retained message make a dead device look alive? +
What can I check on a topic? +
Can I watch a whole fleet without adding every topic by hand? +
What happens when the broker itself goes down? +
Explore next
Related Features
Network Device Monitoring
SNMP switches, routers and firewalls, polled by an agent the same way.
Explore ->Monitoring Workflows
The builder behind the MQTT alerts: rechecks, escalation gates and maintenance windows.
Explore ->Server Alerts
Route MQTT incidents to eight notification channels alongside the rest of your alerts.
Explore ->Linux Server Monitoring
The agent that holds the subscription also monitors the box it runs on.
Explore ->See how Fivenines compares to other tools
Read our guide to the best infrastructure monitoring tools in 2026.
Find out which sensor went quiet, not just that the broker is up
14-day trial. No credit card required.
No credit card · 2-minute setup · Cancel anytime