The manager can tell something else when a device goes down, a backup fails or a CVE matches a version you run. One URL per target, and no agent anywhere.
A webhook is an HTTP request the manager sends when something happens to your fleet — a device stopping answering, a backup failing, a CVE matching a version you run. You give it a URL, tick the events it should carry, and choose the shape of the body. Nothing else is needed: there is no queue to run and no agent to install.
Any number of webhooks can subscribe to the same event, and each is delivered independently — a dashboard that wants everything and a phone that wants only the serious things are two webhooks, not one with rules.
Sixteen, and each one names what fired it:
| Event | Fires when |
|---|---|
| Device Offline | A poll failed and the host did not answer on the network either. |
| Device Not Accessible | The host answers on the network but the poll failed — usually a management service that has stopped listening rather than a device that is down. |
| Device Online | A device that was offline answers again. |
| Device Rebooted | A reboot the manager performed. |
| Device Upgraded | A RouterOS or firmware upgrade finished on a device, with the versions it moved between. |
| Bulk Upgrade Complete | A whole batch or queue finished, with the counts of succeeded and failed. |
| Backup Complete / Backup Failed | A backup finished or failed, whether started by hand or by a schedule. |
| New RouterOS Version | MikroTik published a version on a channel the manager watches. Not tied to a device. |
| Security (CVE) Alert | A published CVE matches the RouterOS version a device actually runs. |
| Security Patch Available | A release whose changelog fixes a security issue is newer than what a device runs. |
| LTE Data Warning / LTE Data Limit Reached | Metered LTE transfer passed the warning percentage, or the monthly limit set on the device. |
| Metric Threshold Exceeded / Metric Recovered | CPU, memory or temperature crossed its alert threshold and stayed there for the configured number of samples, and later came back. |
| BGP Session Down | A BGP peer that was up is not up any more, or its session reset between two samples — its uptime went backwards, so it dropped and returned inside five minutes. A peer you disabled never fires it, one that was already down when the manager started does not either, and neither does any peer on a router that rebooted between the two samples — a restart resets every session on the device at once, and Device Rebooted already reports that cause once instead of once per peer. |
Most events describe something that happened. The metric ones describe something that is still happening, so they need a rule about when a number becomes news. That rule is set once, fleet-wide, under Settings, and overridden per device where a device deserves different treatment.
Three metrics are watched, from the same five-minute samples the device page charts:
| Metric | Default threshold |
|---|---|
| CPU load | 90% |
| Memory usage | 90% |
| Temperature | Off. Normal temperature varies too much by model for a fleet-wide number to mean anything, and plenty of boards have no sensor at all — set it per device, or fleet-wide if your fleet is uniform |
A threshold of 0 disables that metric, and that works in both directions: 0 on a device switches the metric off for it even when the fleet has a threshold, and a value on a device switches the metric on even when the fleet-wide one is disabled. Anything left unset on a device inherits the fleet value.
A metric has to breach for three consecutive samples — about fifteen minutes — before anything is sent. That number is configurable. A router briefly pinned at 100% while it does something you asked it to do is not an incident, and an alert per spike trains people to ignore the channel.
Each crossing then fires once. The condition is latched while it lasts, so a device sitting at 95% for a day produces one message, not two hundred and eighty. When the value drops back under the threshold, a recovery event fires — once — and the latch clears.
A sensor a device does not report is left alone rather than treated as zero: a board with no temperature sensor neither alerts nor recovers on temperature.
The latch lives in memory. Restarting the manager while a device is still over its threshold can produce one repeat notification, which is correct rather than a bug — a live over-threshold condition is a state, not a counter, and the state is still true.
Four shapes, picked per webhook:
event, timestamp, a one-line summary already written for a human, and data with the device, its site and whatever the event carries.X-Title header. Point it at your ntfy topic URL and you are done.{{device.name}}, {{device.host}}, {{device.siteName}}, {{error}}, {{upgrade.type}}, {{upgrade.from}}, {{upgrade.to}}, {{status.routerOsVersion}}. Values are escaped for the content type they land in, so a device name with a quote in it does not break the JSON you are building.The one-line summary can be rewritten per event, on the same form, if the default wording does not suit the target that reads it.
By default a webhook is fleet-wide: every device, every subscribed event. It can be narrowed to sites, to device tags, or to both. Within one kind the test is "any of" — two sites means either site. Between the two kinds it is "and" — sites plus tags means a device in one of those sites that also carries one of those tags.
Events that do not name a device — a new RouterOS release, a finished bulk upgrade — are delivered to a narrowed webhook anyway. There is no device to test against, and silently dropping them would be worse than sending one message too many.
Tags are the way to say "only the gateways" or "only the customer sites". There is no device type in the manager to filter on, and inferring one from configuration is guesswork; a tag is something you decided.
A device is polled every minute, and the offline event fires on the first failed poll. For a dashboard that is right. For a phone at three in the morning it is not: a link that flaps and comes back is indistinguishable from an outage.
Hold offline alerts for takes a number of minutes, per webhook. The device must still be down when that time has passed for the alert to go out; a flap that clears in between produces nothing at all. Zero — the default on every webhook, existing ones included — keeps the immediate behaviour.
Two things follow from that, and both are deliberate. A target that was never told the device went down is not told it came back, so a quiet night does not end with a recovery message about an outage you never heard about. And the wait is not a countdown in memory: the manager records when the outage started and asks on every poll whether it has lasted long enough, so restarting the manager mid-wait delays nothing and loses nothing.
Quiet hours are deliberately not offered. A schedule silences real outages at eleven on a Sunday morning just as effectively as it silences flapping at three in the morning; the delay attacks the flap instead of the clock.
Every request carries X-Webhook-Event with the event name and X-Webhook-Delivery with a unique id for that delivery, so a receiver can discard a duplicate.
Set a secret and the body is signed: X-Webhook-Signature: sha256=<HMAC>, computed over the exact bytes sent. Verify it on your side before acting on anything — a webhook URL is a URL, and anyone who learns it can post to it.
Custom headers can be added for targets that authenticate with one, an API token for instance. They are stored encrypted, the same way device passwords are, and the values are never shown again after saving — the form shows that a value is set, not what it is.
Delivery is a single attempt with a ten-second timeout. There is no retry: a target that is down misses that event, and the manager does not build a backlog to replay at it later. The result of the last attempt — the HTTP status, or the error — is kept and shown on the webhook, which is where to look when messages stop arriving.
Test sends a fixed test payload to the URL with the current settings, including the signature and any custom headers, and reports what came back. Use it after every change: the common failures are a target that wants a header you have not set, and a URL that quietly returns a 4xx.
Webhooks are managed by admins, and the events they carry are fleet-wide unless you scope them.