Alert rules
Every rule WISPMap checks, its severity and how long it waits, and how to change them.
Updated 10 November 2026
WISPMap checks your network every 15 seconds. When a rule finds a problem it opens an incident, which is what your team gets told about. One problem is one incident: a backhaul down with ten sites behind it is a single outage, not eleven alerts.
The rules
Waits is how long the problem must last before the incident opens, so a passing glitch doesn't page anyone. Rules without a wait open at once (an outage still needs a device to miss 3 pings in a row first).
| Rule | Severity | Waits | What it means |
|---|---|---|---|
| Outage | from the devices (see below) | — | Devices down, with the root cause and everything cut off behind it. (always on) |
| Link down | from the devices (see below) | 2 min | A link is down while both ends are still reachable: traffic is on another path. (delay at least 2 min) |
| Running on backup | major | 60 s | OSPF sends traffic over a backup link (higher cost) because the normal path is down or degraded. |
| OSPF not up | major | 2 min | A running link whose OSPF adjacency isn't Full: it can't carry traffic, e.g. a backup that would NOT take over. |
| Device degraded | warning | — | Packet loss or high latency on a device that still answers. |
| API not answering | warning | 3 min | Ping works but the RouterOS API (or SNMP, on other makes) doesn't: service off, firewall, address list or SNMP community. |
| API login refused | warning | — | Ping works but the collector's RouterOS login (or SNMP v3 user) is rejected. |
| UPS battery needs replacing | warning | — | A UPS read over SNMP reports that its battery needs replacing (its own battery test). |
| High CPU | warning | 10 min | CPU at or above the threshold for the whole delay. (threshold adjustable (default 90 %)) |
| High memory | warning | 10 min | Memory at or above the threshold for the whole delay. (threshold adjustable (default 90 %)) |
| Site on battery | major | 2 min | Mains power lost at a site with battery monitoring (its power device's voltage). Not raised for solar sites: they run on battery every night. |
| Battery low | major | 60 s | A monitored site's battery below its low level (critical below the critical level), with a rough runtime estimate. Same incident as "on battery". |
| Battery wearing out | warning | — | A monitored site's battery drains at least 40 % faster in its last 3 power cuts than it did 1-6 months ago (3 or more cuts then): it is probably wearing out, or the site now draws more power than it did. Measured from the site's own power cuts. |
| PoE fault | major | — | A router's PoE-out port reports a short circuit, overload or voltage too low: the device it powers is off. Says which device that is when a link is on that port. |
| Weaker wireless signal | warning | 15 min | A wireless link's signal at least 6 dB below its normal level (the median of its past week) for the whole delay: a dish knocked out of alignment, water in a connector, new interference or something in the path. |
| Low SNR | warning | 10 min | A wireless link's signal-to-noise ratio below 15 dB for the whole delay: it falls back to slow rates and loses packets. Only for radios that report SNR (the older wireless package). |
| BGP session down | major | 60 s | An enabled BGP session on a reachable router isn't established: an upstream provider, a peer, or the iBGP session to another POP. Major for an upstream (eBGP), a warning for iBGP. Sessions you disabled on the router don't count. |
| Fewer BGP routes | warning | 10 min | A BGP peer sends less than half the routes it normally does (its median over the past day): a filter change, a problem on the provider's side or a partial table. |
| No internet route | major | 2 min | Routers that used to reach the internet have no default route at all: every POP they could leave through is gone (upstreams down, or cut off from all of them). They still answer, so nothing looks down, but their customers are offline. Needs collector 0.7 or newer. |
| Traffic moved to another POP | warning | 2 min | Routers that normally reach the internet through one POP now leave through another: that POP's upstream, or the path to it, is down. WISPMap follows each router's default route to the POP where its traffic leaves. |
| Collector offline | critical | — | No data from a collector for 3 minutes. Its devices show as unknown, not down. |
Outage severity
An outage takes its severity from the devices in it: the most serious one decides. Each device's role gives it a weight:
| Role | Outage severity |
|---|---|
| Core router | critical |
| Router | major |
| Backhaul | critical |
| Access point | major |
| Switch | major |
| CPE | warning |
| Other | warning |
Each device's criticality then adjusts that: critical always makes it critical, high at least major, low at most a warning. Because every device in the outage counts, a low-criticality backhaul with towers behind it is still serious. Set both on the device (device settings).
Change a rule
Owners and admins change rules in Admin → Alert rules. For each rule you can:
- switch it off (except Outage, which is always on). Switching a rule off closes its open incidents without a "resolved" message;
- give it another severity. Lowering a severity also lowers the incidents that are open now;
- change its delay (rules that wait). Link down can't wait less than 2 minutes, or every power cut would also show up as a link down first;
- change the threshold of High CPU and High memory (50-100 %, default 90 %).
Empty fields use the rule's default. Changes apply within 15 seconds.
Who hears about what
Severity decides who gets a message: each notification channel gets incidents of its chosen severity and worse. See who gets alerts.