What's New

This page is a tour of what GridNMS does today, grouped by capability rather than by release. GridNMS Cloud picks up new capabilities automatically. Self-hosted instances are told when a new release is available and apply it when you choose. Linux and macOS log forwarders can update themselves when you turn on auto-upgrade; collectors are updated by re-running the installer. See Updates for how delivery works.

Service Monitoring

Model a service — “Customer Portal,” “Internet Access at the Denver office” — as a graph of the components it’s actually built from: managed devices, discovered applications, plain endpoints, or active checks, wired together with hard and soft dependencies. GridNMS rolls health up the graph for you, so a degraded cache reads as degraded, not a false down, and a failed database takes the service with it. Every check runs from one of your own collectors, so internal services — an intranet app, an internal DNS server — are covered right alongside internet-facing ones. See Service Monitoring.

• Checks survive a collector outage. Service checks follow the same collector assignment rules your devices do, so if the collector running a check goes offline, GridNMS re-homes the check onto another healthy collector that can reach the target. If none can, the check reads unknown rather than falsely reporting the service down.
• A latency chart per check, in the service graph. Expand any check inside a service’s dependency graph to see its own response-time history, so you can tell an outright failure from a gradual slowdown without leaving the view.
• Service-level objectives. Give a service an availability target over a rolling window and its graph shows attainment, error budget remaining, and how fast that budget is burning right now. A built-in burn-rate detection can alert you while there’s still budget left to protect.
• Click a red segment to find out why. Any red or amber slice of a service’s status timeline opens an evidence drawer naming the failing monitor, its target, the reason it reported, the response time, the collector that observed it, the events raised in that window, and the individual check results behind the failure — with a shareable link to the same view.
• Alerts name the cause, not just the detection. A service alert’s subject and body carry the service, component, impact and the specific failure — for example Website — DOWN (Web frontend: HTTPS 502 Bad Gateway) — and grouped Cases carry the same detail.
• The graph flags what happened in the window. A component that went down and recovered inside the range you’re viewing is marked as such, instead of looking identical to one that was healthy the whole time.

Detections & alerting

• Ready-made telemetry detections. GridNMS ships a library of built-in, vendor-neutral detections — CPU and memory utilization, temperature, UPS battery, interface errors and discards, latency degradation, and unexpected device reboots. They work the same way on every supported vendor, arrive disabled by default (no day-one alert storm), and you enable just the ones you want under Configure → Logs and Events → Detections. Each threshold detection clears itself when the reading recovers.
• Detections update themselves. New built-in detections are delivered automatically as they’re released — like the vendor and service-name reference data, with version tracking. Your own edits, enable/disable choices, and deletions are always preserved.
• Interface thresholds. Set traffic and utilization thresholds directly on an interface. Breaches raise events through the same detection pipeline as everything else, and recovery is recorded when the value comes back down.
• Container thresholds. Alert on a container’s CPU, memory, or network and disk I/O right from its detail drawer on the Containers page. See Container Monitoring.
• Durable collector offline alerting. GridNMS reliably alerts you when a collector goes offline and clears the alert when it reconnects, so a site that drops off is never missed.
• Maintenance windows. Schedule planned downtime for devices or sites so expected outages don’t generate noise. Notifications are suppressed for the window, and upcoming maintenance is shown on the dashboard and in reports.
• Silence a flapping device without losing its events. For a device that blips but is otherwise fine, turn off Reachability Alerts on its Overview tab. Up/down events are still recorded and still group into cases; only the email or page stops, and only for reachability — a real fault on that same device still reaches you. GridNMS records who turned it off and why. See Notifications.

Cases & events

• Cases are the alert surface. Related events are grouped into a single case, and the case — not the individual event — is what notifies you. Case detail includes a timeline viewer for the case’s member events (expandable rows with a field summary) and a panel explaining why the case was created. See Cases.
• Case rules with priority. Write your own grouping rules for how events roll up into cases. When more than one rule could match, the highest-priority rule wins — one case, no duplicates.
• A permanent event record. Events are immutable, append-only records of what happened — they’re never edited or overwritten. Investigation status (open, closed, ownership) lives on the case instead. The events list shows which case each event belongs to, with a Hide case-managed events toggle to focus on what isn’t already being handled.
• Clearer events list. Events show the detection that produced them, how many log lines matched, and a richer description — with a one-click view matching logs link to jump from an event to the underlying logs.
• Notifications link straight to the source. Email and webhook notifications deep-link to the exact event or case they’re about.

Devices & configuration

• Device configuration backup & diff. GridNMS backs up device configurations on a schedule, keeps a version history, detects real changes (ignoring volatile lines like timestamps), and shows side-by-side diffs. Each device gets a Config tab with versions, changes, the full config, and download. See Configuration backups.
• Automatic device identity. Make, model, software version, operating system, and DNS name are detected automatically and shown (and editable) on the device overview. A daily system scan keeps interfaces and identity details current, including forward and reverse DNS cross-checks.
• API-based monitoring — Cisco Meraki. Monitor cloud-managed devices through the vendor’s API, alongside your SNMP and SSH devices. Manage API credentials under Configure → API Credentials and attach an API target per device or per device class.
• Wider device reach. Devices whose SSH login only supports interactive prompts (common on appliances) can be polled, and per-device SSH credential overrides are honored even when they differ from the device’s class.
• GridNMS can create the SSH key for you. Rather than generating a key pair yourself and pasting the private half in, select Generate a key for me on a device’s SSH credentials. GridNMS keeps the private key in its encrypted store — it’s never displayed — and hands you the public key to install on the device. See Devices.
• More from an agentless server. A Linux or macOS server monitored over SSH now also reports network throughput per interface and identifies its own make and model; Linux adds per-disk read and write throughput. No agent, still just a read-only login. See Server Monitoring.
• On-demand collection. Run a single data collector on demand from a device’s detail page, instead of re-running the whole pack, with clear reporting if it fails.
• Scan one host on demand. Discovery can check a single address instead of a whole network — useful for confirming one new host before you onboard it. GridNMS still verifies the address sits inside a network the collector is allowed to reach. See Discovery.

Monitoring & collectors

• Vendor monitoring packs. Ready-to-use monitoring packs for Cisco (IOS-XE and Nexus), Juniper, Fortinet, Aruba, APC/UPS, Arista, HPE/Aruba, QNAP, and generic SNMP hosts — so common gear is monitored correctly out of the box.
• MIB browser. Browse the MIBs behind your monitoring packs directly in the app, grouped by the pack that provides them.
• Clearer service and topology views. Discovered services are labelled with their well-known names (for example ssh (22/tcp)), with duplicates de-duplicated for a cleaner picture.
• Smarter metric collection. Polling intervals are tuned per data point so fast-changing counters stay responsive without over-collecting slower metrics.
• Load-balancing profiles with a standby option. Choose how devices are assigned across the collectors at a site — including a dedicated backup collector that stays idle and only takes over when the primary collector goes offline.
• Log forwarders that update themselves. Turn on Auto-upgrade for a Linux or macOS forwarder and it installs new releases through its collector — downloading in the background, restarting once, and rolling back on its own if the new version doesn’t start. Upgrade now checks for a release on demand.
• Fleet-wide forwarder policies. Set automatic updates on for every newly approved forwarder, push that setting across the whole fleet in one action, and generate a shared install token so new hosts are approved the moment they connect instead of queuing for a decision.
• Forwarder hosts identify themselves. A connected forwarder reports its manufacturer, model, and operating system name and version automatically — no module to turn on — so a host’s entry in your inventory is filled in without you typing it.
• NVIDIA GPU monitoring. Turn on the GPU Metrics module for a Linux host’s forwarder profile and every NVIDIA GPU in that host reports its utilization, memory, temperature, and power draw, with a card and charts per GPU on the host’s Metrics tab.
• Windows Event Log collection. Pick the Event Log channels a Windows host should send — Security and System with one action, or any channel you name.

Logs, detections & cases

• Log management and search. Collect syslog and SNMP traps from your devices, search across all of them, and drill into the fields that matter with a live fields sidebar. Traps carrying binary and text payloads are decoded correctly, and forwarded syslog carries the full structured record — not just the message text — so more fields are searchable.
• Container and service logs land already sorted. Logs shipped from a host’s journal arrive under the container or system service that produced them — for example docker:my-app or linux:sshd — instead of one undifferentiated bucket, so you can search one service without writing a parser first. Every parser GridNMS applies is listed on the Parsers page.
• Detections and cases. Turn log and telemetry patterns into detections that raise events, and automatically group related events into cases so a storm of alerts becomes one actionable item.
• Configurable retention. Choose how long to keep logs — by age or by a fixed storage size — so your history stays predictable.

Backup & restore

• Full configuration export & import. Export your entire GridNMS configuration (devices, credentials, monitoring, users and roles, notifications, detections, dashboards) as a single password-protected, encrypted file. Import previews every difference — row by row, field by field, classified New / Changed / Unchanged — and applies only what you tick.

API & automation

• API tokens. Create personal access tokens under Profile → API Tokens to script against GridNMS. A token can carry your full user permissions or a narrower scope you choose at creation — read-only, a specific set of permissions, or limited to particular sites — so an integration only gets the access it actually needs. A published API reference documents the endpoints.

Reference data

• Data feeds. Curated reference datasets — device vendor identification and well-known service names — update automatically over the collector’s existing connection, with per-dataset status, version history, and the ability to refresh or roll back to a specific version (Configure → Service Management → Data Feeds).
• Local overrides. Override any reference entry with your own value under Configure → System Configuration → Reference Data — your overrides survive dataset updates.

Access control & security

• Site-aware roles and permissions. Roles can be scoped down to individual sites, so a user can be given access to only the sites they’re responsible for. Every view, list, and action respects each user’s authorized sites, and you can switch your active site on the fly.
• Mandatory multi-factor authentication. Sign-in is protected with a passkey as your second sign-in step, an authenticator-app fallback, and recovery codes, with policy controls for your organization.
• Hardened collector connections. Per-site IP allowlisting and one-time diagnostic access tokens give you tighter control over what each collector can reach.
• Single sign-on decides group membership. Write rules that read an attribute your identity provider sends at sign-in — a group claim, a department, a job code — and place the user in the matching GridNMS group automatically, re-checked every time they sign in. A group an administrator set by hand is never overwritten. See SSO Mapping.
• Scheduled log forwarder credential rotation. Replace each forwarder’s ingest credential on a schedule instead of by hand. Rotation runs one forwarder at a time and the old credential keeps working until the host confirms the new one, so nothing stops delivering. See Managing Log Forwarders.

Self-hosted

• Update notice with one-click apply. Self-hosted administrators see an in-app banner when a new server release is available and can apply it with a single confirmed click — the update health-checks itself and rolls back automatically if something goes wrong. See Updates.

Account & deployment

• Self-serve signup and customer portal. Sign up, manage your subscription, and handle billing from a self-service portal.

Quality of life

• About dialogs everywhere. Every GridNMS screen can tell you exactly which version you’re running, with a copy-to-clipboard summary for support requests.
• Consistent device search. Anywhere the app asks you to pick a device, you get the same fast, searchable device picker.
• Shareable Graph Explorer views. The query you build lives in the page address, so you can bookmark a view or paste the link to a colleague and they see the same results — and Back, Forward, and refresh behave the way you’d expect. See Graph Explorer.
• Richer dashboard panels for services and collectors. The Service Status panel adds a 24-hour timeline per service, and the Collector Status panel shows a row per collector with its heartbeat age, owned devices, and CPU, memory, and log-volume sparklines. See The Dashboard.