New · Release 2026.04, Multi-tenant audit exports & SLA dashboards now liveSee changelog →
Network operations
Network monitoring that connects SNMP, topology and incidents
Monitor network availability, SNMP MIB-II targets (sysDescr, uptime, interfaces), infrastructure mapping, and topology context without mixing unrelated tenant data.
Product illustration · sample data
Infrastructure / Live
142/142 healthy
CPU avg
34%
Memory avg
62%
api-prod-01.acme.io98ms
db-primary.acme.io12ms
worker-eu-03.acme.ioSSL expires 14d
Product proof
Already live in the product
Backed by app modules
Running in production today: network monitoring, the telemetry hub, infrastructure mapping, and SNMP, incident and push-ingest APIs — each scoped to your own organization.
Protected app route: /network-monitoring
How it works
Built around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
Network availability views
SNMP v2c polling with samples and forecast API
Device and IP mapping with force-directed topology
Telemetry hub: incidents, RCA, metrics and syslog HTTP ingest
Operational history
Workflow
What teams can do here
Step 1
Track network status
Step 2
Map devices and IPs
Step 3
Investigate availability issues
Step 4
Connect network signals to reports
How it works
How it works
01
Add SNMP targets
Register the devices you want to watch as SNMP targets with a host or IP reachable from the worker, a port and a community string. The community is encrypted at rest per tenant, so credentials are never stored in plain text.
02
Poll standard MIB-II data
A scheduled task polls every active target and reads the standard MIB-II identifiers: system description, system uptime and the interface count. Each poll is stored as a timestamped sample, and the last description and uptime are cached on the target for quick reference.
03
Tie devices to your IP inventory
A target can be linked to an IP allocation from the asset and IP inventory, so a polled device is connected to the record of what that address is and who owns it, rather than floating as a loose hostname.
04
Build history and spot drift
Because every poll is retained as a sample with its own timestamp, you accumulate a history of description and uptime changes. A device that reboots shows its uptime counter reset, and stale samples are pruned on a schedule to keep the store lean.
Example
A worked example
A typical manufacturing plant runs 14 switches and 4 routers across two buildings. Each is added as an SNMP target — community strings encrypted per tenant — polled every five minutes for system description, uptime and interface count, and linked to the IP allocation that records which rack it sits in. When the packaging-line switch is power-cycled by a contractor over the weekend, Monday's samples show its uptime counter reset to minutes, so the network engineer can point to a timestamped record of exactly when it rebooted instead of arguing from memory.
FAQ
Frequently asked questions
Which SNMP values are polled from each device?
The poller reads the standard MIB-II objects: system description, system uptime and the interface count. Each of those, plus any error message, is written to a poll sample so you can see both the current reading and how it has changed over time.
Which SNMP versions are supported?
Targets are configured for SNMPv2c with a community string, and the model also carries an SNMPv3 option. Whichever is used, the community secret is encrypted per organization at rest rather than kept as plain text.
How often are targets polled?
Each target has its own poll interval in seconds, defaulting to five minutes, and a scheduled task walks every active target on that cadence. You can raise or lower the interval per device depending on how closely you need to watch it.
How does network monitoring connect to my asset inventory?
An SNMP target can be linked to an IP allocation record, tying the polled device to the address, subnet and ownership already tracked in the asset and IP inventory. That keeps the network view and the asset register describing the same thing.
How is this different from the network telemetry hub?
Network monitoring is the availability and polling layer: SNMP targets, samples and history. The telemetry hub builds on the same app to add pushed metrics and syslog, incident correlation, root-cause reports and remediation playbooks for deeper operations.
Where is the community string kept?
The community is stored encrypted using per-tenant encryption, so it is scoped to your organization and never written in clear text. It is decrypted only when a poll runs against the target it belongs to.
Do I need to install a collector appliance on my network?
No appliance is required — targets are polled from the platform worker, so a device just needs to be reachable from it. For data that cannot be polled, the telemetry hub accepts pushed metrics and syslog over HTTP instead.