Find the hop that dropped the packet.
Then find the change that caused it.
Datadog Network Monitoring covers the traffic between your services, the devices it passes through, the path it takes and, since DASH 2026, the configuration changes on those devices. We implement it by role and by device, keep it scoped, and run it every month so the flow map still explains the outage a year from now.
Quick facts
Related
- Infrastructure Monitoring, the hosts at each end of the flow
- Container Monitoring, the pods that the flows run between
- APM, the request on top of the connection
The network stops being the thing everyone blames and nobody can see
The application is healthy. The database is healthy. The requests between them are timing out, and the only evidence is a retransmit counter on a box nobody can log into. Network Monitoring puts the connection, the device and the change on the same screen as the service.
Who talks to whom, and how badly. Cloud Network Monitoring draws the flows between services from the Agent, with throughput, retransmits and latency per pair, tagged with the same env and service values as the traces.
The hardware in the middle. Network Device Monitoring collects interface throughput, errors, discards and device health over SNMP from the routers, switches, firewalls and load balancers the traffic crosses, with the topology drawn for you.
The path, hop by hop. Network Path shows the route traffic takes from a source to a destination and where along it the latency or the loss appears, and DNS Monitoring shows when the lookup was the slow part.
The change that broke it. Network Configuration Management keeps every version of a device's running configuration, and the startup configuration where the profile supports it. It diffs them line by line and ties a drop in performance to the change made just before it.
A probe on every host, a subnet sweep that finds the printers, and a config history that starts the day after the outage
How it bills. Cloud Network Monitoring is billed per host, counted every hour and billed on the high-water mark of the lower 99 per cent of usage, the same method as Infrastructure hosts, and every host it monitors also needs an Infrastructure Pro or Enterprise plan. Its flows are recorded over five-minute windows. Network Device Monitoring is billed per device, a device being any appliance with its own IP address that is polled over SNMP. NetFlow is billed per million flow records, by retention period, and Network Path per thousand tests. Network Configuration Management builds on Network Device Monitoring and needs it configured on every device it collects from. Datadog publishes the rates. We publish nothing here, because the price is not the problem. The configuration is.
The configuration traps. Cloud Network Monitoring is one flag in the Agent configuration, and when that configuration is fleet-wide, so is the meter. SNMP autodiscovery on a wide address range monitors everything that answers. A device without a vendor profile falls back to the generic profile and reports interface basics, not the metrics that matter for that model. Configuration history begins when it is enabled, so the first outage with evidence is the first one after the rollout, not the one that prompted it. None of this looks like an error. All of it reaches the invoice or leaves the dashboard empty when it matters.
Field noteThe most common gap we see is scope. Cloud Network Monitoring was switched on in the shared Helm values, so every node in every cluster is a network host, including the batch clusters whose only traffic is to an object store. The flow map is enormous and nobody reads it.
Field noteSNMP autodiscovery was pointed at the office range to find the core switches. It found the core switches, the access switches, the wireless controllers and every device with a management interface. The device list grew in an afternoon and has never been pruned.
Field noteThe firewall change that caused the outage was made on the console, at speed, by someone fixing a different problem. There is no record of it. Configuration Management would have had the diff, if it had been enabled the month before instead of the month after.
Field noteThe flow map shows IP addresses instead of services on half the estate. The hosts there carry no service tag, so the flow has nothing to join to. The traces for the same requests are fine, and nobody connects the two views.
Scope by role. Devices by profile. Config history before the next change, not after it.
A new rollout starts with LaunchPad, which runs the implementation as a managed project with a named engineer and a written scope. If any part of Network Monitoring is already on, a Datadog HealthScan comes first. It is read-only and fully automated, and it reports which hosts and devices are on the meters and what each is sending before we change anything. Either way, the sequence is the same.
- Inventory the network. The VPCs and the peering between them, the on-premises devices and their vendors, the load balancers, the DNS resolvers, and the paths the customer-facing traffic takes.
- Scope Cloud Network Monitoring by role. Hosts on the path between the customer and the data first. Batch, build and bastion hosts excluded, with the reason written down.
- Onboard devices with a profile each. Every router, switch and firewall listed with its vendor, its SNMP credentials and the profile that matches it. Autodiscovery, if used, on a narrow range with a tag filter.
- Enable Configuration Management on the devices that matter. SSH credentials, host key verification on, running configuration collected, and startup where the profile supports it. A first snapshot taken before anyone changes anything.
- Build the monitors and the dashboard pack. Retransmit rate per service pair, interface errors and saturation per device, path latency on the routes that earn money. Thresholds come from a fortnight of real data.
- Hand over, in writing. Which hosts and devices are in scope and why, and which profiles were used. The host and device counts on the day we finished.
Access is admin on the Datadog organisation, read access to the configuration management repository, and SNMP and SSH credentials for the devices in scope, held in your secrets store rather than ours. We do not need console access to the devices to implement Network Monitoring, and we do not ask for it.
Devices get replaced. Credentials rotate. The flow map grows a region.
A switch is swapped for a newer model and the old profile no longer matches. An SSH key is rotated and configuration collection fails quietly for a month. A new VPC is peered in and its hosts are on the meter before anyone decided they should be. Managed Observability is the monthly service that keeps Network Monitoring matching the network it watches.
Every month, we review the meters. Cloud Network Monitoring host count against the role list, device count against the device inventory, flow volume against last month. Anything that moved gets a reason or a fix.
Collection is kept honest. Every device is checked for a matching profile, live credentials and a configuration snapshot taken in the last cycle, so the history is there on the day it is needed.
Monitors earn their place. A monitor that has not fired for a real reason in a quarter is retired or rebuilt. Alert noise is a configuration problem, and configuration is what we run.
The incident is ours to take. Under Critical Support our engineers answer the page the network raised, 24x7, and fix the cause rather than report it. Datadog has published that our work reduces mean time to resolve incidents by 40 to 60 per cent.
We operate the stack. You own the product.
An implementation partner switches the probe on and hands over. A managed partner is still there when the core switch is replaced in March and the profile stops matching. We are the second kind. The Agent configuration, the device list, the profiles and the decisions behind them stay in your Datadog organisation and your repositories, documented, and you can take them in-house whenever you choose.
Datadog is our proof, not our headline. Datadog certified one managed provider globally. We are it. The Powered by Datadog accreditation means Datadog's own engineers reviewed how we instrument, alert, respond and report. We are also a Datadog Advanced Partner, ISO 27001 certified and Cyber Essentials Plus certified, with offices in Cardiff, London and Dublin.
Datadog Network Monitoring, answered plainly
How is Datadog Network Monitoring billed?
There are two main meters. Cloud Network Monitoring is billed per host. Datadog counts the hosts with it enabled every hour. It bills on the high-water mark of the lower 99 per cent of usage, the same method as Infrastructure hosts. Network Device Monitoring is billed per device, so every router, switch and firewall polled over SNMP is a line on the meter. Flows are recorded over five-minute windows. NetFlow and Network Path have meters of their own. We do not publish prices. The meters are what we tune, and the first tuning decision is which hosts and which devices are in scope at all.
What is the difference between Cloud Network Monitoring and Network Device Monitoring?
Cloud Network Monitoring comes from the Datadog Agent. It watches the traffic a host sends and receives, so it shows which services talk to which, over what, and where the retransmits and the latency are. Network Device Monitoring comes from SNMP. It watches the hardware the traffic passes through, so it shows interface throughput, errors and device health for routers, switches, firewalls and load balancers. Most estates need both, and most have only one of them switched on.
What is Datadog Network Configuration Management?
Network Configuration Management extends Network Device Monitoring. It collects the running configuration from each device over SSH, using the profiles that ship with the Agent. Where the profile supports it, it also collects the startup configuration. It keeps a history of every version and shows two versions side by side with the changed lines marked. It can also roll a device back to an earlier configuration through a Private Action Runner. The history starts on the day it is enabled, which is a reason to enable it before the outage rather than after.
Does Cloud Network Monitoring need the Agent on every host?
It needs the Agent, with the system probe enabled, on every host whose traffic you want to see. It does not need to be on every host you have. Enabling it in the Helm chart or the configuration management for the whole fleet puts every host on the meter, including the ones whose traffic nobody will ever look at. We enable it by role, starting with the hosts that sit on the path between the customer and the data.
What does Critical Cloud do with Network Monitoring every month?
Managed Observability runs it. Every month we review the Cloud Network Monitoring host count and the device count against the previous month. We check that new devices have a matching SNMP profile and credentials, and confirm configuration collection is still succeeding on every device. We retire monitors that no longer fire for a real reason and report what changed. Under Critical Support our engineers also take the page when the network goes wrong, 24x7.
- Datadog products: every product, and how we implement and run each one
- Datadog Infrastructure Monitoring: the hosts at each end of every flow
- Infrastructure Observability Accelerator: infrastructure, APM and logs operational in four weeks
- Datadog pricing and cost optimisation: the whole bill, not just the network
The network, visible. The change, on record.
Tell us which outage was blamed on the network last. We will tell you what Network Monitoring would have shown, what it is showing today, and what it takes to get from one to the other.