Proactive Internet Connection Monitoring

Continuously monitor your internet connection and receive alerts before downtime impacts your team

Which Layers of Your Internet Connection Should You Actually Be Monitoring?

Internet connectivity isn't binary. A connection can be reachable but degraded, stable by ping but saturated at the WAN interface, or fully pingable while DNS is broken and nothing actually loads. Reliable internet connection monitoring checks each of these layers independently: reachability, latency, jitter, bandwidth, DNS resolution, and application-layer responses. Every change gets timestamped and stored.

Paessler PRTG covers all of these layers from a single platform, with dedicated sensors for each check and no additional agents or third-party integrations required. Alerts fire the moment a threshold is breached, and historical data is retained per sensor. That gives you a full record of connection behavior, useful for active troubleshooting and ISP escalation documentation alike.

Supported protocols: ICMP, SNMP, HTTP/HTTPS, DNS, NetFlow v5/v9, IPFIX, sFlow, jFlow

Supported technologies: Routers, modems, firewalls, WAN interfaces, DNS servers, ISP gateways, web servers, external IP addresses

Download PRTG Trial

PRTG is compatible with all major vendors, products, and systems

Full Visibility Into Your Internet Connection

Know Before Your Users Do

The first sign of an internet outage shouldn't be a user complaint. The Ping v2 Sensor polls any reachable IP address (your ISP gateway, an external DNS server, a target host) via ICMP echo requests at configurable intervals. The moment response time exceeds your defined threshold, PRTG sends an alert via email, SMS, or push notification. Every polling result is logged automatically with a timestamp and duration, so you have a full incident record before a single support ticket lands.

ICMP-based polling checks reachability at configurable intervals, around the clock
Threshold-based alerts fire via email, SMS, or push notification the moment limits are breached
Every polling result logged with timestamp, response time, and status; packet loss tracked when the sensor is configured to send multiple pings per interval (the default)
Downtime duration is tracked automatically. You're not reconstructing it from user reports after the fact
Works against any reachable IP: your ISP gateway, an external DNS server, or a specific target host

Intermittent Problems Don't Disappear, They Show Up in the Data

Sporadic connection instability, the kind users complain about, but that disappears before IT gets to it, leaves a trace in PRTG. The Ping Jitter Sensor sends a series of ICMP requests per polling cycle and calculates statistical jitter, logging execution time and jitter value every cycle. Network performance issues that come and go don't vanish from the record. They're in the graph when you go looking. Polling runs at intervals, so single-second micro-outages may not surface. But sustained degradation patterns always do.

Ping Jitter Sensor sends multiple ICMP requests per polling cycle and calculates jitter as the variation in response times across those requests.
Execution time and statistical jitter value logged every polling cycle; latency and packet loss are separate metrics measured by the Ping v2 Sensor
Graph view makes degradation patterns visible across hours, days, or weeks
Configurable polling interval lets you tune detection sensitivity for your environment
Historical data is exportable

Overloaded or Actually Broken?

"The internet is slow" describes two completely different problems with different fixes. A saturated WAN link needs a capacity conversation. ISP-side degradation needs an escalation call. Without data, you're guessing which one it is.

The SNMP Traffic Sensor measures traffic in and out on your WAN interface in real time and historically. That one data point tells you whether the link is hitting capacity or whether internet speed is normal while connection quality drops. Sustained drops in connection speed with normal bandwidth utilization point to the ISP. A maxed-out WAN interface points to capacity. Two different problems, two different responses. You'll know which before you pick up the phone.

SNMP Traffic Sensor covers WAN traffic in/out on any SNMP-capable router or firewall
Bandwidth utilization visible in real time and historically
Spot sustained link saturation vs. latency and packet loss events side by side
Set thresholds on bandwidth usage to get alerted before the link is fully saturated
Pair with latency data from ICMP sensors to build the complete picture

See Why IT Professionals Trust PRTG

Start monitoring your infrastructure in minutes. No professional services, no complex configuration, no risk.

Free download

PRODUCT OVERVIEW

Build Your Case Before Calling Your ISP

When internet service provider (ISP) performance degrades, the response is almost always "it's not on our end." Without documented evidence, troubleshooting that conversation goes nowhere. PRTG gives you two complementary tools to build the case.

The Traceroute Hop Count Sensor shows the number of network hops to any external target and alerts you when the hop count changes, which can indicate upstream path changes or reroutes. Separately, a Ping v2 Sensor pointed at your ISP's gateway IP builds a continuous, timestamped latency and availability record against an external reference point you don't control. Together, these give you documented data rather than anecdote when you open an ISP escalation ticket.

Traceroute Hop Count Sensor shows the number of hops to a target and alerts when that count changes, indicating upstream path changes or reroutes
To isolate which hop is degraded, add Ping v2 Sensors to individual hop devices; this requires manual setup per hop
Ping v2 Sensor pointed at your ISP gateway IP builds a continuous latency and availability record on the ISP side of the connection
Historical graph shows exactly when external response time degraded and for how long
Data is exportable for ISP escalation documentation

One View Across Every Location

Branch offices and remote sites without on-site IT staff are visibility blind spots. You don't find out something's wrong until someone at that site calls.

A PRTG remote probe installed at each site monitors local connectivity independently, keeping polling going regardless of what's happening between that site and your core server. When the connection is up, results flow into one central dashboard. When that link goes down, the probe continues polling locally; the core server flags the probe as disconnected, which is itself a visible alert state that tells you exactly where to look.

Remote probes monitor each site independently; local polling doesn't depend on the central server being reachable
Per-site uptime and connectivity data centralized in one dashboard when the link is up
Geo-map view available for a multi-location status overview at a glance
If the WAN link between a site and the core server goes down, the probe continues polling locally; the core server flags the disconnection as an alert state; data gaps may occur for classic probes during a full outage (multi-platform probes buffer and sync on reconnect)
Scales from two offices to dozens of locations without architecture changes

How PRTG Monitors Internet Connections

Beyond the core reachability sensors, PRTG covers additional layers of internet connection health as part of a complete network monitoring setup. Here's what each method does and where it fits.

HTTP v2 Sensor

A server can be pingable and still returning a 500 error. The Ping v2 Sensor won't catch that. The HTTP v2 Sensor connects to a target web server, checks whether a page or element loads, and validates the response code. It measures bytes received, load time, and response code, so you know whether the server is up and actually serving content correctly.

DNS v2 Sensor

"The internet is down" is frequently a DNS problem in disguise. The physical connection is fine; nothing resolves. The DNS v2 Sensor queries a DNS server, resolves domain name records, and compares results against a defined filter. It reports record count, resolution status, and response time. A simple ping check won't surface this failure scenario at all.

Flow Traffic Analysis

For environments where routers and firewalls actively export flow data, PRTG can receive that data and analyze network traffic by source, destination, and protocol, giving you Top Talkers, Top Connections, and Top Protocols. This goes beyond interface-level bandwidth and shows you which devices or applications are driving internet usage on your WAN link.

Note: flow analysis requires a router or firewall that supports and is configured to export flow data. Not all devices support this. For devices without flow export, the SNMP Traffic Sensor provides the bandwidth view.

External Availability Checks

Your internal probes can only tell you what's happening inside your network. The Cloud Ping v2 and Cloud HTTP v2 Sensors test whether your internet-facing services are reachable from outside, using PRTG cloud locations distributed across four continents.

Two constraints worth knowing: Cloud Ping v2 measures reachability and response time using a TCP connection attempt (not ICMP echo). And the monitored device must be reachable from the internet; it's not suitable for internal-only hosts unless they are reachable from the internet (e.g., via a published service endpoint, reverse proxy, or other secure exposure method). For public-facing services, this gives you reachability data that an internal sensor can't provide.

TCP Port Monitoring

One layer deeper than host-level ping. The Port v2 Sensor connects to one or more TCP/IP ports on a target device to verify that a specific service is actually listening and the OS is managing connections. You'll see whether a monitored service port is open or closed. Ping alone won't tell you that.

free downLoad

Manual Checks vs. PRTG Internet Connection Monitoring

What do you need to know?	Checking Manually Checking Manually	With PRTG With PRTG
Is the internet down?	Checking Manually Users call IT	With PRTG Alert sent as configured, e.g. with timestamp
Did something happen earlier?	Checking Manually Unknown, no record	With PRTG Full polling history per sensor, exportable
Is the link congested or broken?	Checking Manually Run an internet speed test (one point in time)	With PRTG Continuous SNMP Traffic Sensor data, real-time and historical
Did the upstream path change?	Checking Manually Manual traceroute, no history	With PRTG Traceroute Hop Count Sensor alerts on hop count changes; Ping v2 Sensors on external IPs build the latency record
Status across multiple sites	Checking Manually Phone calls from branch staff	With PRTG One dashboard, all locations via remote probes

free downLoad

“I would recommend PRTG because it has helped us significantly improve service uptime by highlighting important alerts that would otherwise result in a system failure or service disruption if action was not taken. Thanks to PRTG, we can ensure that The Ritz London’s network and IT systems are five-star, just like the hotel.”

Richard Isted, IT Manager

The Ritz London

”GESAC increasingly focuses on innovation to improve the quality of services offered and the experience of passengers handled every day by Naples Airport. Thanks to PRTG, we finally have unified, automatic, and continuous monitoring of the airport network and can guarantee quick and timely interventions.”

Domenico Ciervo, GESAC ICT Manager

Naples International Airport

”As an international company, PRTG is ideal for us. If something went down half way across the world, we wouldn’t be woken up – we can rely on PRTG to identify the problem and alert us before it occurs – enabling the right person, in the right time zone to resolve the problem. At the end of the day, if we’re to provide an internal network experience for our employees that meets expectations, we need a tool like PRTG to be successful.”

Barry Kelly, Systems Engineer

Skyscanner

Paessler PRTG Network Monitor licenses & pricing

Choose the PRTG Network Monitor subscription that's best for you.

License Name	Price	License Details	Get started	Pricing Details
PRTG 500	^$200	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 50 devices
PRTG 1000	^$358	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 100 devices
PRTG 2500	^$742	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 250 devices
PRTG 5000	^$1,300	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 500 devices
PRTG 10000	^$1,642	per month paid annually	Buy now Buy now	Enough to monitor multiple aspects of 1000 devices

Over 100,000 Customers Worldwide Love Paessler

Internet Connection Monitor: Frequently Asked Questions

How is PRTG different from running a periodic speed test?

A speed test runs once and gives you a number. PRTG runs continuously, stores every result, and sends you an alert when something goes wrong. If your connection degrades overnight, a speed test won't tell you. PRTG already has the record by the time you check in the morning.

Does PRTG monitor wired (Ethernet) connections differently than wireless (Wi-Fi)?

Not at the IP level, which is where PRTG operates. The sensors don't see the physical medium underneath. They see the network interface. That said, if you want wireless-specific metrics, PRTG can monitor access points and switches via SNMP separately. For standard internet connection monitoring, the ICMP and SNMP sensors work the same either way.

What protocols and hardware do I need for router and modem monitoring?

It depends on what you want to measure. Reachability and latency checks (Ping v2, Ping Jitter) only need a reachable IP (no special hardware). WAN bandwidth via the SNMP Traffic Sensor requires SNMP enabled on the router or firewall. Flow-based traffic analysis requires the device to actively export flow data, and not all devices do. PRTG's sensor setup shows you exactly what each sensor needs before you deploy it.

What happens when the internet connection itself goes down?

Single-site setup: if the core server loses connectivity, outbound alerts via email or SMS may not get through until the connection comes back. The server also needs internet access to run cloud-based checks. Multi-site setup with remote probes works differently. Each probe keeps polling locally regardless of what's happening with the WAN link back to the core server. The core server flags the disconnection as an alert state. Classic probes will have a data gap for that period; multi-platform probes buffer and sync when the connection recovers.

Can PRTG monitor Microsoft 365 and cloud service reachability?

Yes, with HTTP v2 Sensors pointed at Microsoft 365 endpoints. You'll get a continuous record of whether those URLs are reachable and returning valid responses from your network. What it won't catch is a Microsoft-side issue that doesn't affect the HTTP response code. For that you'd need Microsoft's own status pages. But for the question "can my users actually reach it from here," PRTG gives you the answer.

How do mobile alerts work?

PRTG sends notifications via email, SMS, and push through the PRTG app. Each sensor has its own notification triggers, so you can set different thresholds, escalation paths, and on-call schedules per sensor. The right person gets alerted. Nobody needs to be watching a dashboard.