Skip to main content

Monitoring

The Monitoring page provides network device monitoring, uptime tracking, tag-based rollup alerting, and discovery tools. It includes ping, TCP port, and HTTP endpoint checks, plus ARP-based and port-range network scanning.

Open Monitoring

Licensing

Network Monitoring — uptime monitors, tag rollups, and network discovery (the Scan tab) — is part of the Network Monitoring module. Without it in your license the Monitoring and Device Health menu items are greyed out with a lock and clicking one opens the License page instead; creating a monitor or a tag is refused, and a network scan returns "network discovery requires the Network Monitoring module". Monitors created earlier keep running. Trials and development builds unlock it.

Overview​

The page is split into three tabs:

  1. Monitors — create and manage uptime monitors
  2. Scan — ARP sweep with optional TCP port-range scan
  3. Tags — group monitors into rollup alert sets with shared health rules and dependency suppression

Monitors Tab​

Stats Dashboard​

A strip of tiles at the top of the tab summarizes fleet health:

  • Total — monitors in the list
  • Up — currently responding
  • Down — confirmed failing (past the retry threshold)
  • Unknown — never checked, or not yet confirmed either way
  • Skipped — not being checked because the monitor's parent dependency is down
  • Tags Down — number of Monitor Tags currently rolled up to down (with a · N deg degraded count when applicable). Hidden when no tags are configured.
  • Avg Response — average of the last response time across the monitors that are currently up, in milliseconds

Stats refresh on every state change, and a 30-second poll keeps the counts aligned with the server even if a live update is missed.

Filtering​

  • Search box — filters by name, IP, state, tags, or the id of the linked device
  • Tag chips — click a tag to filter; multiple tags combine as OR. Clear removes all tag filters. Each chip carries a small dot showing the tag's current rollup state — green/red/amber/grey/dashed for up/down/degraded/unknown/inert.
  • The count beside the search box reads 12 of 40 — matches versus total.

Bulk Edit​

Click Bulk Edit in the filter row to enter multi-select mode. Each row grows a checkbox and an action bar appears above the list showing 3 of 12 selected, with:

  • Select all (filtered) / Clear — operate on the current visible filter set
  • Add Tag — add the chosen tags to every selected monitor
  • Remove Tag — strip the chosen tags from every selected monitor
  • Replace Tags — replace each selected monitor's tag set with exactly the chosen tags (empty picker strips all tags)

The tag pickers in the bulk modal list the rollup tags defined on the Tags Tab. Click Apply to run the change, or Cancel to back out. Click Done in the filter row to exit bulk mode.

Monitor Cards​

Each row displays:

  • Name and, when a device is linked, a (D#123) link — click it to open that device's editor over the list without losing your filters or scroll position
  • paused badge when the monitor is disabled
  • Type · Target · every Ns summary line, followed by depends on #id and power zone #id links when those are configured. The depends-on link opens the parent monitor's editor; the power-zone link opens the zone.
  • Tag chips — colored by the live rollup state of each tag the monitor belongs to (up = green, down = red, degraded = amber, unknown = grey). A purple suppressed by <tag> chip appears when a tag further up the dependency chain is currently down: that tag's rollup macros are muted, though this monitor's own alarm still opens normally. A monitor carrying only typed-in tags shows those as grey chips.
  • last: check timestamp and response time in milliseconds
  • error: text from the last failed check (shown while the monitor is not up)
  • Meta icons — email recipient count, SMS recipient count, and an override flag when the monitor bypasses notification-profile time windows
  • State badge — up, down, skipped (parent dependency is down), or unknown (never confirmed either way)
  • Alarm chip — a red alarm chip appears when the monitor (or a tag, on its card) has an open event in the alarm center; click it to jump to the Alarms page

When a monitor changes state, its row briefly flashes green (up) or red (down) so the transition is visible at a glance.

Card Actions​

Icon buttons at the right of each row:

  • Pause / Play — stop or resume checking. Pausing also closes any open alarm for the monitor, since a paused monitor can never recover on its own and clear it.
  • Run (play-arrow) — check now, without waiting for the interval
  • History (clock) — open the response-time history (see below)
  • Edit (pencil) — open the monitor's settings
  • Delete — remove the monitor after a confirm prompt; its open alarm is closed too
A paused monitor disappears at the next restart

Only enabled monitors are loaded when the server starts, so a monitor you left paused is not on this list after a restart — it looks deleted even though its record (and its reserved name) still exists. Treat Pause as a short-term action for commissioning and maintenance windows; if you are done with a monitor, delete it.

Deleting is refused while another monitor still names this one under Depends on Monitor — remove or re-point the child monitors first. The same protection applies from the other side: a device or zone that a monitor references cannot be deleted until the monitor is.

A refused delete leaves the monitor stopped

When a delete is refused you get an error toast, but the monitor has already been taken out of the running list — it stops checking and stops appearing here, while its record survives. It comes back, checking again, at the next server restart. So if a delete fails, clear the dependency and delete it properly rather than walking away from the page.

History Modal​

The History icon (clock) opens a full-size chart of the monitor's response times. Every check is written to storage as it happens, so the chart is intact after a server restart — it is re-read from storage each time you open it, not from whatever the page happened to observe while it was loaded.

The chart shows:

  • Blue line — response time per check (lower = faster)
  • Red dots — failed checks
  • Orange bells at the top with a dashed vertical line — checks that fired a notification under the pre-alarm-center sender. These are historical markers only; notifications sent today are logged on the alarm event instead, so no new bells appear.
  • X-axis — time labels across the window (includes the date when the window spans more than one day)
  • max label — top-left corner shows the peak response time in the window

Below the chart, four tiles summarize the window: Checks, Success Rate, Avg Response, and Max Response. When any check failed, a line beneath the tiles counts the failures.

How far back the chart goes

The chart always plots the most recent 100 checks, so its span depends on the check interval — 100 checks at 30 s covers under an hour; at 1 hour it covers four days. For long-window analysis use Device Health rather than this chart.

Stored check results (and tag rollup transitions) are kept for the number of days set by monitor_history_retention_days on the Data Retention page — default 30 — and older rows are removed by the nightly maintenance job.

Creating a Monitor​

Click Add Monitor in the filter row, or use the Monitor button on a Scan tab row to prefill from discovery.

Monitor Types​

  • Ping (ICMP) — fastest; tests reachability only. The right default for cameras, access points, processors, thermostats — anything where "is it on the network" is the question.
  • TCP Port — opens a TCP connection to one port and closes it again. Use this when the box answers ping while the service behind it is dead (a hung NVR, a stopped web server, a DSP that stopped listening on its control port).
  • HTTP/HTTPS — issues a plain HTTP GET/POST/HEAD and looks at the response status.

Basic Fields​

  • Name — the monitor's name. Names must be unique across all monitors. A save that collides shows a red toast that still reads "monitor created" and leaves the dialog open — red toast plus a dialog that didn't close means the save failed; rename and save again.
  • Type — Ping (ICMP), TCP Port, or HTTP/HTTPS
  • Target — the bare IP address or hostname of the host, for every type: 192.168.1.50 or nvr.site.lan
Never put a URL in Target

Despite the https://example.com placeholder shown on HTTP monitors, the check builds its own request as http://<target>:<port>/. If you enter http://192.168.1.50 or https://nvr.site.lan, the monitor tries to resolve a host literally named http or https, never reaches the device, and reads permanently down. Enter the host on its own and set the port separately.

The request is always plain HTTP — there is no TLS option on this page — so a device that only answers on HTTPS (443) cannot be checked with an HTTP monitor. Monitor those with a TCP Port check on 443 instead: it confirms the listener is alive, which is what the alert is really for.

Check Configuration​

  • Check Interval — 30 seconds, 1 minute, 5 minutes, 15 minutes, 30 minutes, or 1 hour. The first check runs the moment you save (and again at every server start), then repeats on this interval.
  • Timeout (seconds) — how long one check waits before it counts as failed (1–30)
  • Retries (consecutive fails before down) — how many checks in a row must fail before the state flips to down (1–10). Until that many failures stack up, the monitor holds its previous state — so a brand-new monitor sits at unknown rather than going down on the first miss. One success resets the count.

Interval × retries is your true detection time: a 5-minute interval with 3 retries means an outage is confirmed roughly 15 minutes after it starts. Tighten the interval on anything that needs a fast page; leave slow-polling gear at 15–60 minutes so the log stays readable.

Type-Specific Fields​

  • TCP Port — Port (required; a blank port falls back to 80)
  • HTTP/HTTPS — Method (GET / POST / HEAD) and Expected Status Code
Expected Status Code is not applied yet

The field is saved with the monitor, but the check currently treats HTTP 200 as the only success regardless of what you enter. A device that answers 302, 401 or 403 on its root page will read down even if you set that code here. For gear like that, use a TCP Port check on the same port instead.

Associations​

  • Associate with Device — link the monitor to a GEM device. The card then shows a (D#id) link straight to the device editor, which is what makes a red row actionable at 2 a.m.
  • Depends on Monitor — while the chosen parent is down, this monitor is skipped instead of checked (see Monitor Dependencies)
  • Power Zone (auto-reboot on down) — power-cycles a zone when this monitor goes down (see Auto-Reboot on Failure)

Tags​

Comma-separated values typed into the Tags field. They become filter chips on the Monitors tab.

Prefer the Tags tab for new groupings

The comma-separated Tags field is still honored for filtering, but new rollup groupings belong on the Tags Tab. Tags created there carry a health rule, dependency edges, and rollup notifications — the typed-in string only filters the list.

Notifications​

State changes raise and clear a stateful event under the Network Monitor Down alarm definition — the link in this hint opens that definition directly on the Alarms page's Definitions tab; the alarm center sends the notifications (batched, acknowledge-aware, delivery-logged) to the recipients configured here. These recipients are always notified — even when that definition has its own notify steps, which add site-wide routing on top rather than replacing the per-monitor lists. Notifications are explicit: a monitor with no recipients of its own is dashboard-only — its alarm opens and shows on the Alarms page, but nothing is emailed by default. The same rule applies to a tag's rollup recipients.

  • Email Recipients — pick from GEM users or type addresses directly; leave empty (along with SMS) for a dashboard-only alarm
  • SMS Recipients — pick from GEM users or type numbers directly
  • Bypass notification profile (always send) — ignores day/hour windows on the recipient's notification profile. Use for critical alerts that should page at any hour.

The alarm event opens once per outage and clears on recovery, so there is one notification per transition — no per-monitor throttle is needed. When several monitors fall over together, the alarm center collects everything raised inside a short window (30 seconds by default) into a single digest email per recipient list rather than one message per monitor. The email carries the alarm name, severity, message, source and time, plus acknowledge and shelve buttons; the SMS is a one-line version with a +N more tail.

At the bottom of the modal, the Enabled checkbox controls whether the monitor starts checking when you press Save.

Send Test Notification

Send Test Notification sends a real email and SMS to the monitor's recipients immediately, and lists the per-recipient result inline (email → x@y.com: sent), so you can prove alerting works before an outage does it for you. Two things to know:

  • On a monitor that already exists, the test uses the saved recipients — press Save first, or you will be testing the old list.
  • Test sends always ignore notification-profile day/hour windows, so a "sent" here does not prove a 3 a.m. outage would reach that person. Check the Notification Profile too, or tick Bypass notification profile.

With no recipients configured the button reports "no notification recipients configured" and sends nothing.

Real-Time Updates​

The page is live — leave it open on a laptop during commissioning and it updates itself:

  • every completed check refreshes that row's state, timestamp and response time
  • a state change flashes the row and re-counts the tiles at the top
  • monitors and tags added, edited or removed elsewhere (another admin session, or the AI Assistant) appear and disappear here without a reload
  • tag rollups, memberships and dependency edges follow the same live path, so the tag chips on a monitor row track the real rollup state

The tiles also re-poll every 30 seconds, so the counts stay honest even if a live update is missed.

Scan Tab​

Network discovery combining an ARP sweep with an optional TCP port-range scan. Use this tab to enumerate hosts on the LAN, identify services on remote subnets, and onboard devices or monitors in one pass.

Settings​

  • Network Interface — required. Picking one auto-fills the IP Range from that interface's subnet.
  • IP Range — required. CIDR (192.168.1.0/24) or range form. A CIDR block wider than /16 is refused outright, and the ARP pass is bounded to two minutes regardless — an absurdly broad target used to be able to occupy the controller for hours, during which no device polling, alarm evaluation or door command runs. A sweep that hits the time limit returns the hosts it did find rather than nothing.
  • Port Range — comma and dash syntax, e.g. 23,80,443,5900-5902. Required unless Quick Scan is ticked.
  • Quick Scan (skip port scan) — skip the TCP port scan entirely and only discover hosts via ARP. Returns results in seconds; greys out the Port Range field.

Click Start to scan, Stop to cancel a running port scan. Starting a scan clears the previous results and any row selections.

How the Scan Works​

  1. An ARP pre-pass enumerates every responder in the IP range. Each host row is populated with IP, MAC, vendor, and an initial driver suggestion.
  2. If Quick Scan is unchecked, the TCP port scan runs afterward. Open ports stream in live and merge into the matching host's row, and the driver suggestion re-ranks as new ports arrive.
  3. Hosts that respond to the port scan but not to ARP (cross-subnet, ARP blocked) appear as bare rows with no MAC or vendor.

Results​

Each row shows:

  • Select — checkbox for bulk monitor creation; the header checkbox toggles all rows
  • Vendor — from the MAC OUI lookup; falls back to Unknown
  • IP — clickable when the host is already a GEM device; opens that device's editor in a modal in place (no navigation away from the scan)
  • MAC
  • Open Ports — port pills, added live as the scan progresses
  • Suggested Driver — top match with a confidence score and the primary reason. Low-confidence suggestions (<40%) render in muted grey. For hosts already in GEM the column shows the device's configured driver display name instead of a guess.
  • Actions — Import opens the device creator prefilled with IP / MAC / port; Monitor opens the monitor creator prefilled from the host (a host with 80 or 443 open comes in as HTTP, a host with exactly one other open port as TCP on that port, everything else as ping). The name is derived from vendor and last octet, e.g. axis_54.

Hosts already linked to a GEM device are highlighted in green, show an Already in GEM pill with the device name/label and ID, and the Import button is disabled.

Fix the Target on an HTTP prefill before saving

The Monitor prefill puts a full http://… or https://… URL in Target for hosts with 80/443 open. Saved as-is, that monitor never reaches the device and sits permanently down — strip the scheme so Target is just the IP, or switch Type to TCP Port with 80/443, which is the better check for a web endpoint anyway. See Never put a URL in Target.

Reused on the Devices page

The same scanner is embedded as the Scan Network modal on the Devices page (with the bulk-monitor controls hidden) so you can onboard hardware without leaving the device admin.

Bulk Monitor Creation​

Select multiple hosts via row checkboxes to create monitors for all of them in one click. A bar appears above the results table when any rows are selected:

  • N selected — how many hosts will be monitored
  • Tags — comma-separated tags applied to every created monitor (pre-filled with discovered)
  • Create N Monitors — runs the same prefill logic as the per-row Monitor button for each selected host and saves them one after another, with no review step. A toast reports how many were created and how many failed; a failure is usually a name collision with an existing monitor, since monitor names must be unique.
  • Clear — deselects all rows without creating anything

Selections survive incremental port-scan updates but are wiped when a new scan starts.

Because there is no review step, hosts with 80 or 443 open are created as HTTP monitors carrying a URL in Target — the shape that never reports up. Two clean ways to work: tick only the hosts you want as plain ping monitors and bulk-create those, then add the port-specific ones one at a time with Monitor; or bulk-create everything and immediately fix the HTTP ones on the Monitors tab (they are the rows that go down first).

Tags Tab​

Monitor Tags group correlated monitors so a single rollup alert covers a shared outage instead of N member alerts. Each tag is a first-class record with its own health rule, dependency edges, and notification fan-out.

Why Tags​

Without tags, every monitor that goes down opens its own alarm and pages its own recipients — a flapping uplink turns into dozens of alerts for one root cause. (The alarm center merges whatever lands in the same 30-second window into one digest, but an outage that unfolds over minutes still arrives as a stream of separate emails.) A tag adds one clear rollup alert that names the outage — "Cameras down" rather than sixteen camera alerts — and tag dependency edges keep a downstream group quiet while a deeper outage is already firing.

Build a whole tag set in one ask

The AI Assistant's bulk_create_monitor_tags skill provisions many rollup tags in a single request — members, health rules, and upstream dependency edges together — e.g. "set up the standard rack rollup: network (all switches + APs), cameras anchored on the NVR, access, and av — with cameras/access/av depending on network." It validates the whole batch and rolls back if any tag fails. Create the underlying monitors first (bulk_create_monitors); tags group monitors that already exist.

Tag Cards​

Each tag card shows:

  • Label (or Name when no label is set) and a state badge: up / down / degraded / unknown / inert
  • Rule — anchor monitor name, threshold percentage, "any member down", or "all members down". On an anchor rule the monitor name is a link that opens that monitor's editor, so you can check the anchor without hunting the list for it.
  • Members — count plus how many are currently down
  • Depends on — chip list of upstream tags
  • Recipient summary — N email · M sms, plus ↓ down-macro and ↑ recovery-macro chips naming the macro. Click either chip to open that macro in a reference modal over this page — the tag list, its live rollup states and any card you have expanded all survive the look-up.
  • A red — nothing happens on transition (no recipients or macros) hint when neither is configured. The rollup alarm still opens and shows on the Alarms page — it just notifies no one (dashboard-only).
  • History, Edit, and Delete action buttons. Deleting a tag detaches its members and drops its dependency edges; the monitors themselves are untouched.

The inert — needs setup badge means the tag is configured so it can never roll up to down — an anchor rule with no anchor chosen, or a threshold rule left at 0%. Inert tags are safe: they come from the legacy tag migration or an unfinished edit and fire nothing until you finish configuring them.

Creating or Editing a Tag​

Click Add Tag (or the edit icon on a card). The modal exposes:

Identity

  • Name — the tag's identifier and the text of its filter chip on the Monitors tab. Keep it lowercase with no spaces (core, cameras, av_rack) — nothing rewrites what you type. It must be unique; a duplicate is refused with tag 'core' already exists.
  • Label — optional friendly name (Core Network). When set it is what tag cards, monitor-row chips and alarm messages show. Left empty, the name is used.
  • Description — optional free text, searchable from the Tags tab search box

Health Rule

  • Anchor monitor (tag mirrors anchor state) — the tag simply reports whatever the Anchor Monitor reports. The anchor does not have to be a member of the tag: point a Cameras tag at the NVR, or a Wireless tag at the controller, and add the individual cameras or APs as members for visibility. Leaving the anchor empty makes the tag inert.
  • Any member down — down as soon as any one member is down, up only when every member is up. The "page me if anything in this rack drops" rule; it never reads degraded, because one down member is the alert condition. Prefer this over a 1% threshold — a threshold can't represent "any" once a tag has more than 100 members.
  • All members down — down only when every member is down, up when every member is up, degraded in between (at least one member down).
  • Threshold % of members down — down once that percentage of members is down; degraded below the threshold with at least one member down. Threshold (% members down) accepts 1–100.

Under any member-based rule, a tag reads unknown — not up — while any member has never completed a check. Give a new tag one full interval before you trust the badge.

Members — pick monitors via the searchable picker. Tags can have any number of members.

Deleting a monitor that a tag points at

Deleting a monitor removes it from every tag's member list. If it was a tag's anchor, that tag loses its anchor and quietly goes inert — it stops rolling up until you pick a new anchor, and the card shows inert — needs setup. Re-check your tags after retiring hardware.

Depends On (Upstream Tags) — pick the tags this one sits behind (cameras depends on network). While any upstream tag anywhere up the chain is down, this tag's down and recovery macros are muted, so only the deepest outage acts. Saving a dependency that would loop back on itself is refused with cycle detected — refusing dependency.

Trigger Macros on State Change

  • On Down — run macro — fires once per rollup transition into down. Suppressed when an upstream tag is also down.
  • On Recovery — run macro — fires once when the tag transitions down → up. Receives outage_duration_ms in context.

The macro context for both fields includes monitor_tag_id, monitor_tag_name, monitor_tag_label, previous_state, new_state, trigger_monitor_id / trigger_monitor_name / trigger_monitor_ip, and rollup_reason. See Macros — Context Simulator for previewing these values while authoring steps.

Rollup Notifications

A tag raises a Monitor Tag Down alarm event only when it rolls up fully down — the link in this hint opens that definition directly on the Alarms page's Definitions tab; the alarm center sends the notifications to the recipients configured here (empty = dashboard-only, no notification). A tag that recovers to up — or eases back to degraded — clears the alarm, because a partial outage is already visible through the individual monitors' own alarms. Down/up macros run independently of notifications.

  • Email Recipients / SMS Recipients — pick from GEM users or type in addresses/numbers
  • Alert Throttle — minimum time between rollup macro runs for this tag (no throttle, 5 min, 15 min, 1 h, 6 h, or 24 h default; per-direction). Notifications are per alarm-event transition and don't need throttling.
  • Bypass notification profile (always send) — same semantics as on per-monitor notifications

Suppression Semantics​

  • Dependency suppression — a monitor whose parent is down stops being probed and reports skipped. It counts on the Skipped tile, but it never goes down, so it raises no alarm and pages nobody; only the root cause does. An alarm it had already raised stays open until it genuinely recovers.
  • Storm batching — when a shared outage downs many monitors at once, each raises its own alarm event, but the alarm center batches their notifications into one digest email per recipient list over a 30-second window (plus the tag rollup alarm, when a tag covers them).
  • Upstream tag suppression (macros) — when any transitive upstream tag is currently down, a dependent tag's down/up macros are muted. Only the deepest still-up→down transition runs macros.
  • Boot-time resync gate (macros) — a tag's recovery macro only fires if its down transition was seen in this session, so a tag that boots down doesn't emit a phantom recovery.

Tag History​

Click the history icon on a tag card to open the rollup transition timeline:

  • A colour-coded timeline bar of state segments (up / down / degraded / unknown) with a legend; hover a segment for its start, end and duration
  • A table of every transition, newest first: Time, Transition (previous → new badges, with the outage length beside a recovery), Reason (for example anchor 'core_switch' is down or 3/8 members down (≥30% threshold)), Triggered By (the member monitor that caused it, with its IP), and Dispatch (the macro that ran, named and clickable — it opens in the same reference modal; email/sms counts appear on older rows, since today's sends are logged on the alarm event instead)

Rollup transitions are kept for the same number of days as monitor check results — one retention setting covers both (see Data Retention).

Legacy Tag Migration​

Tag names typed into the per-monitor Tags field on an older version are turned into real tag records the first time the upgraded server starts. Migrated tags come in with the anchor rule and no anchor set — inert, firing nothing — until you open each one and choose a rule. The migration can never increase alert volume.

It runs once and marks itself done (a system attribute named monitor_tag_migration_done, visible on Attributes), so a migrated tag you delete does not come back on the next restart.

Auto-Reboot on Failure​

Set Power Zone (auto-reboot on down) on a monitor and GEM sends a reboot command to that zone the moment the monitor drops from up to down — that is, after the consecutive failures set in Retries. Useful for:

  • Cameras and NVRs that hang
  • Routers and switches that need periodic reboots
  • Equipment without remote management

Know exactly when it fires, so you can predict it on site:

  • Once per outage, on the up → down edge only. A monitor that was already down when the server started, or that has never confirmed a state (unknown), does not trigger a reboot. There is no repeat attempt while it stays down and no back-off — if the reboot doesn't help, nothing further happens until the monitor recovers and fails again.
  • The zone's device must support a reboot command. Managed PDUs and smart outlets (WattBox, APC, CyberPower, Shelly, TP-Link and similar) do. A plain relay contact that only has on/off does not, so nothing happens. Test it first from the zone's controls, or from the device's Commands tab.
  • Need a different sequence — off, wait, on, or power-cycle a whole rack — set Run Macro On Activate on the Network Monitor Down alarm definition instead and put the sequence in a macro. See Alarms.
Don't auto-reboot critical life-safety equipment

Don't assign a power zone to monitors for HVAC controllers, access control panels, or other equipment where an unattended reboot could cause harm.

Monitor Dependencies​

Depends on Monitor models "don't bother probing B while A is down":

Monitor 1: Internet Gateway (8.8.8.8)
Monitor 2: Local Router     (depends on Internet Gateway)
Monitor 3: Camera           (depends on Local Router)

While a parent reads down, each monitor pointing at it is skipped instead of probed: it stops sending traffic at gear that cannot answer, shows skipped, counts on the Skipped tile, and raises no alarm. Only the root cause pages anyone. When the parent recovers, the children resume on their next interval.

Suppression reaches one level, not down the whole chain

A monitor is skipped when its direct parent is down. A skipped parent does not suppress its own children — in the chain above, if Internet Gateway goes down, Local Router is skipped, but Camera sees a parent that is skipped (not down), keeps probing, fails, and raises its own alarm.

For a deep tree, either point every downstream monitor at the same top-level parent (Camera depends on Internet Gateway, not on Local Router), or leave the chain as-is and group the branch in a tag whose upstream tag covers the root — the tag edges collapse what is left into a single rollup.

The alert itself is a plain alarm notification for the monitor that went down — it does not enumerate the downstream monitors affected. To see the blast radius, open the Alarms page, or read it off the Monitors tab, where the skipped rows sit right under the failed parent.

Dependencies vs Tags

The per-monitor Depends on Monitor link is a one-to-one parent/child relationship that pauses checking while the parent is down. Tag dependencies are tag-to-tag edges that mute rollup macros on downstream tags without touching the check schedule. Use both together: dependency links so GEM stops probing what it cannot reach; tag edges so one outage produces one page.

Public IP Tracking​

Alongside the monitors on this page, GEM keeps an eye on the site's public (WAN) IP address. Once an hour it asks a public lookup service what address the site presents to the internet and stores it as the system attribute wan_ip, which you can read on the Attributes page (target System).

The address is tracked on every site. Emailing about a change is opt-in — set alert_wan_ip_change to true in the controller's configuration file to be notified. When it is on, a change emails the system recipients with the previous and current values and the controller's local addresses, which is useful on a site whose ISP hands out dynamic addresses and a reminder to update anything that whitelists the site by IP (remote support access, a VPN peer, an SSL/DNS record).

Most sites do not want this mail: a dynamic address can change several times a week, and a notification nobody acts on trains people to ignore the ones that matter. Turn it on where the address is genuinely load-bearing.

Tracking runs whether or not you have created any monitors, and whether or not alerting is on. To stop the hourly lookup entirely, set monitor_wan_ip to false.

Voice assistant — "is the internet down?"​

The monitors on this page are what lets the voice assistant answer connectivity questions. Its network_status skill reads the live up/down state of every enabled check, plus the banked check results for "did it drop?" questions. No other voice skill reads this data — check_health sweeps zone attributes (low batteries, a device whose online attribute is false), which says nothing about whether the router, the ISP link or the NVR is reachable.

Questions it handles:

The user asksWhat it reads
"is the internet down?", "do we have internet?", "is the wifi working?"The WAN/ISP-facing checks, picked out by name, tag, or a well-known ping target like 8.8.8.8
"is anything down?", "is something wrong with the network?"Every enabled check, leading with what's down
"is the camera server up?", "is the NVR online?"One check, matched by the name you gave it — so name monitors the way the household refers to them
"did the internet go out today?", "how many times has it dropped?"Drop counts and minutes down over today, the last 24 hours, or the last week

It follows the Depends on Monitor chain, so when a check is down only because its parent is down the answer names the root cause — "the internet is down, which is why the cameras are unreachable" — instead of reciting ten symptoms. Read-only: it never sends a command, and it never reads back an IP address.

Two answers are worth knowing about because they are relayed verbatim:

  • With no monitors configured it says there isn't any network monitoring set up on this system, rather than inferring that the internet is fine. Configuring at least one WAN check is what turns "is the internet down?" into a real answer.
  • Asked about a specific streaming app, it says plainly that it can only see whether the relevant server or link check is up, not whether the app itself works.

Monitors are site infrastructure rather than controllable zones, so this skill is not scoped to a user's accessible zones. Name a monitor for its uptime check ("Internet", "Camera Server", "Garage AP") and tag the WAN-facing ones — the skill matches on label, name and tag.

  • Alarms — the alarm center that raises, batches and delivers monitor notifications
  • Devices — device configuration
  • Device Health — historical uptime data, licensed by the same module as this page
  • Data Retention — how long check results and rollup transitions are kept
  • Notification Profiles — recipient day/hour windows and channels
  • Zones — power zones used by auto-reboot