The best WAN alert is the one that fires while the link is struggling — not the phone call from the accounts department after it has died. Here is the monitor set that makes OpManager speak first.
Every office learns its internet is down from its users, because users are the only “monitoring” watching the link. OpManager can reverse that with three boring, reliable monitors on the router or firewall that owns the WAN connection. None of them needs an add-on or an agent: the router already counts every byte through its interfaces over SNMP. Your job is to watch the right interface (the WAN port, not the LAN), set thresholds that leave reaction time, and attach a notification profile that reaches a human. Do that and the sequence flips — you get the email while the link is at 95 percent and dropping packets, and the office hears about the problem from you, with a plan attached.
Example thresholds. Sustained matters — one busy minute is a backup job, not an incident.
Discover the router or firewall first (SNMP enabled, credential associated — the earlier pages in this series cover it). Open its snapshot page and look at the interface list: identify the interface that faces the internet by its description, its IP address, or simply by watching which interface’s traffic curve matches office hours. Rename it in OpManager to something a human understands — WAN – Fibre 200 Mbps beats “GigabitEthernet0/1” at 2 a.m. — and pin it where you will see it, on the device snapshot and on your main dashboard.
Interface traffic monitors are the early-warning system. Set a warning threshold around 80–85 percent of the real link speed — and make sure OpManager knows the real speed, because a 200 Mbps link monitored as if it were 1 Gbps will never alarm. Require the breach to persist across consecutive polls before it raises: a single spike is a software update leaving the building; fifteen minutes pinned near the ceiling is a link running out of road. Add a second, critical threshold near saturation so the alarm can escalate in tone as the situation earns it.
A link can be “up” and awful. Rising input errors and discards on the WAN interface mean the physical path — fibre, copper, the ISP’s last mile — is degrading: pages crawl, calls break up, and the interface status stays green the whole time. Add monitors for interface errors/discards with a modest threshold (any steady growth is wrong; a healthy interface sits at or near zero). When this alarm fires, you have the one thing an ISP support call always demands: timestamps and numbers, straight from the router’s own counters.
The router answering SNMP proves the router is alive — not that the internet works. Add an availability check against something just beyond your control: the ISP’s gateway address, or a stable public address, and let OpManager ping it on a short interval. Now the alarm set distinguishes the three failures that feel identical to users: your router is down (no SNMP, no ping), the ISP path is down (router fine, gateway ping fails), or the link is merely saturated (everything answers, utilisation is pinned). Each has a different fix and a different phone call.
None of this matters until it reaches a person. Build a notification profile for WAN events — email to the IT group at warning level, email plus SMS or a helpdesk ticket at critical — and associate it with the router’s monitors. Then rehearse: during a quiet window, temporarily lower the utilisation threshold and generate real traffic, or pull the WAN cable for sixty seconds on a test router. Watch the alarm, the email and the ticket arrive. An unrehearsed alert path is a rumour, and the first live test should not be the day the fibre is cut.
See the discovery and monitor screens these steps live in — the full OpManager setup video walks the console end to end.
▶️ Watch Full VideoNot with its built-in interface monitors — they report totals per interface. Per-user and per-application visibility needs flow data (NetFlow), which ManageEngine sells as the NetFlow Analyzer add-on. The utilisation alarm still tells you when to go looking.
As fast as your polling and alarm cycle: the interface status monitor and the gateway ping fail at the next poll, and the notification profile fires. Shorten the poll interval on the WAN interface if the office is fragile — every minute of interval is a minute of blindness.
Yes — exactly the same three monitors. A failover link that died quietly in March is discovered in the worst possible way: during the main link’s outage in October. Idle links need availability monitoring most of all.