Reference: Ports, Permissions & Alert Variablesv7.0.20
Three quick-reference tables in one place — the firewall ports the appliance uses, the permission areas you assign to user accounts, and the alert classes and template variables you draw on when editing notifications.
This page collects the three lookup tables the rest of the guide points back to: network ports and firewall openings, the permission model, and the alert classes with their template substitution variables.
Network Ports & Firewall Reference
Allow the following through any firewall between the appliance and what it serves or monitors. “Inbound” means toward the appliance.
Inbound to the appliance
| Port | Protocol | Purpose |
|---|---|---|
| 443 | TCP | Web interface and API (HTTPS) — administrators, agents’ enrollment and ongoing update check-ins, API clients |
| 80 | TCP | HTTP redirect to HTTPS |
| 514 | UDP & TCP | Syslog from your devices |
| 9996 | UDP | NetFlow (v5/v7/v9) and IPFIX (its IETF-standard successor) export from routers and firewalls |
| 6343 | UDP | sFlow export |
| 7443 | TCP | Out-of-band OS-upgrade assistant (only during OS upgrades) |
| 5353 | UDP | mDNS announcement (<hostname>.local discovery, optional) |
Outbound from the appliance
| Port | Protocol | Purpose |
|---|---|---|
| ICMP | — | Ping monitoring of every device |
| 161 | UDP | SNMP polling of devices |
| 489 | UDP | Polling enrolled Windows agents |
| Various | TCP | TCP port checks (whatever ports you monitor) and URL trackers (typically 80/443) |
| 25 / 465 / 587 | TCP | Alert email to your SMTP server (per your SMTP configuration) |
| 443 | TCP | Webhook/Slack/Teams/Discord outlets; activation and updates on connected sites |
On monitored Windows hosts
| Port | Protocol | Purpose |
|---|---|---|
| 489 | UDP | Netmon Agent listener (the installer opens this in Windows Firewall for all profiles). The agent only completes a session with an appliance it has enrolled with; scope the rule to your appliance address(es) if your policy requires it. |
The appliance initiates agent communication; agents only initiate HTTPS check-ins during enrollment and update advertisement. Nothing in normal operation requires inbound access from the internet to the appliance — keep it on management networks.
Permissions Reference
The permission areas assignable to user accounts (System → Users and Permissions), as they appear in the product. Permissions are additive; tag restrictions intersect with them (see Core Concepts).
| Permission | Grants |
|---|---|
| Super Admin | Unrestricted access. Implies every other area; not affected by tag restrictions. |
| Overwatch | View the Overwatch status wall. |
| Devices | View device dashboards and device data. |
| Manage Devices | Create, modify, and remove devices; manage discovery ranges, credentials, and device import. |
| VNE | Use the Visual Network Explorer. |
| Logs | Read syslog, Windows event log, and IDS event data. |
| Alert Center | Manage alerting end to end: triggers, routes, outlets, exceptions, templates; read alert history. |
| Reports | Run and manage reports. |
| URL Trackers | Create and manage website monitoring. |
| Tools | Use the network diagnostic tools (ping, traceroute, MTR, SNMP walk, port scan, speed test). |
| Packet Capture | Create and download packet captures. Captures are private to their creator; administrators see all. |
| System Settings | Manage appliance settings: network interfaces, certificate, SMTP, retention, services, licensing. Also gates the browser Terminal. |
| Users | Manage user accounts and their permissions. |
| Agent Admin | Issue and revoke Windows-agent enrollment tokens. |
| API / MCP Access | Mint personal API tokens and approve API/MCP client sign-ins. |
Practical bundles:
- Help-desk viewer — Overwatch, Devices, Logs (+ tag restriction).
- Network operator — Devices, Manage Devices, VNE, Logs, Alert Center, Reports, Tools, URL Trackers.
- Security analyst — Devices, Logs, Packet Capture, Reports, VNE.
- Administrator — everything except Super Admin, reserving Super Admin for one or two named individuals.
Alert Classes & Template Variables
Reference for the log-stream alert classes (the New Alert wizard) and the substitution variables available when editing notification templates (Alerting → Template Editor, and webhook payload templates on outlets).
Log-stream alert classes
Each class evaluates its filter on a fixed cycle (every minute by default) over a sliding lookback window, and fires when the number of matching entries reaches the occurrence threshold.
Syslog — filters collected syslog by:
- Facility (kern, mail, auth, daemon, and the rest of the standard set)
- Severity ceiling — match entries at or more severe than the chosen level
- Contains — one or more text fragments, combined with AND or OR, with an optional invert (“does not contain”)
- Occurrences and lookback window (minutes)
Windows Event Log — filters collected event-log entries by:
- Log (Security, System, Application, …) and Source
- Event IDs — one or more specific IDs
- Severity ceiling, contains text (AND/OR, invertible)
- Occurrences and lookback window
IDS Events — filters intrusion-detection events by:
- Severity
- Source/destination address and port
- Protocol and interface/VLAN
- Occurrences and lookback window
All three classes tie each match to a device, so routing rules can filter the results by device tags like any other alert.
Template variables
Templates substitute {$variable} markers with live values at send time; a variable that does not apply to the event renders empty.
Templates come in two families — the modern log-stream templates and the legacy device-status templates (separate tabs in the editor) — and each exposes its own variables. When you open a template, the editor lists the variables valid for that template beside the editing pane. Always trust that list, and send yourself a test notification to see the substitution with real data. The sets below are representative, not exhaustive.
Log-stream templates (syslog, Windows event log, IDS) draw on the matched event. Available on most:
| Variable | Substitutes |
|---|---|
{$label} / {$device_name} | The device’s display name |
{$device_ip} / {$ip_address} | The device’s address |
{$device_profile} / {$profile} | The device’s profile |
{$device_tags} | The device’s tags |
{$alert_label} | The alert definition’s label |
{$alert_class} | The alert class that fired |
{$severity} / {$severity_name} | Severity as number / as word |
{$count} / {$event_count} | How many entries matched in the window |
{$timestamp} | When the event fired |
…with class-specific fields where they apply: {$facility} and {$message} (syslog); {$log}, {$source}, {$event_id}, {$data} (Windows event log); {$src_ip}, {$dst_ip}, {$src_port}, {$dst_port}, {$proto}, {$iface}, {$vlan} (IDS).
Device-status templates (the Legacy tab — device offline, latency, disk, interface, port, URL, and the rest) draw on the condition that fired: {$host} and {$ip}, {$time}, {$newstatus}, and condition-specific values such as {$threshold} and {$partition} (disk), {$interface} and {$utilization} (interface), {$latency} and {$loss} (ping/latency), {$port} (port checks), {$oid} (SNMP value), {$pattern} and {$ssl} (URL trackers), plus {$notes}. The editor lists the ones valid for each template.
Webhook payload templates additionally support {@variable} markers, which emit the value JSON-safe (quoted and escaped) — use {@...} inside JSON payloads and {$...} in plain text.