PING Monitoring

PING monitoring uses ICMP (Internet Control Message Protocol) to verify network connectivity and measure latency to servers and network devices. This guide covers PING monitoring configuration, interpretation, and best practices.

What is PING Monitoring?

Protocol Overview

PING monitoring sends ICMP echo request packets to a target and waits for echo reply packets.

Measured Metrics:

• Availability: Whether the target responds
• Round-Trip Time (RTT): Time for packet round trip
• Packet Loss: Percentage of lost packets
• Latency Statistics: Min, average, and max response times

Use Cases:

• Server availability verification
• Network connectivity testing
• Latency monitoring
• Infrastructure health checks
• Network troubleshooting

PING vs HTTP Monitoring

PING Advantages:

• Lower overhead (lightweight protocol)
• Network layer monitoring
• Works for any IP-addressable device
• Faster response times
• No application layer required

PING Limitations:

• Cannot verify application status
• May be blocked by firewalls
• Doesn't validate service functionality
• No content verification
• Limited diagnostic information

When to Use PING:

• Monitoring network devices (routers, switches)
• Basic server availability
• Network latency tracking
• Firewall/load balancer monitoring
• Supplement to HTTP monitoring

When to Use HTTP:

• Web application monitoring
• API endpoint checking
• Content verification
• Application-specific health checks

Configuration

Basic Configuration

Service Name (Required) — Descriptive identifier for the service. Example: "Production Database Server", "Router 192.168.1.1".

IP Address / Domain (Required) — Target for PING monitoring. Supports IPv4, IPv6, and domain names. Maximum length: 255 characters.

Project (Optional) — Project assignment for organization.

Enabled (Toggle) — Activate or deactivate monitoring.

Check Interval (Required) — Monitoring frequency in seconds. Default: 180 s (3 min). Minimum is plan-dependent (Free: 300 s, Pro: 60 s, Team: 30 s, Enterprise: 10 s).

IP Address Formats

IPv4 Address

192.168.1.1
10.0.0.50
172.16.0.1
8.8.8.8

IPv6 Address

2001:db8::1
::1
fe80::1
2001:0db8:85a3::8a2e:0370:7334

Domain Name

example.com
server.internal.network
db-primary.production.example.com

PING Check Process

Check Execution

Each PING check performs the following:

1. DNS Resolution (if domain name provided)
2. ICMP Packet Generation
3. Packet Transmission (typically 4 packets)
4. Response Collection
5. Metric Calculation
6. Result Reporting

Default Parameters

Packet Count — 4 packets per check. Standard across most platforms.

Packet Size — 56 bytes data + 8 bytes ICMP header. Total packet size: 64 bytes.

Timeout — 10 seconds per check. Includes all packets and processing.

Interval Between Packets — ~1 second. Brief pause between sequential packets.

IP Address Family

Control which Internet Protocol versions the prober uses to ping your target.

Address Family Options

Auto (Default)

The prober invokes ping without -4 or -6 flags, letting the operating system choose (typically IPv4 if available). No per-family result breakdown is reported.

Use When:

• No specific IPv4/IPv6 requirement
• Target has both IPv4 and IPv6 support
• Backward compatibility preferred

IPv4 Only

The prober forces IPv4 by appending -4 to the ping command. DNS is checked for an A record; if no A record exists, the check fails with a no_record error (distinct from dns or timeout).

Use When:

• IPv6 is not available or disabled
• Specific IPv4 testing required
• Legacy infrastructure

IPv6 Only

The prober forces IPv6 by appending -6 to the ping command. DNS is checked for an AAAA record; if no AAAA record exists, the check fails with a no_record error.

Use When:

• Testing IPv6 deployment
• IPv4 has been deprecated
• Specific IPv6 infrastructure

Both IPv4 and IPv6

The prober pings both IPv4 AND IPv6 independently and reports separate metrics for each family under response.families.ipv4 and response.families.ipv6. The overall check succeeds only if BOTH families are reachable (AND rule). The top-level response.time_ms and response.packet_loss always deterministically mirror the IPv4 (primary) family — they are never a race for whichever family answered first.

Use When:

• Rolling out IPv6 (AAAA records)
• Monitoring dual-stack deployments
• Detecting per-family network issues independently

Both-Mode Details

In "both" mode, each family reports its own result object under response.families.<family> (<family> is ipv4 or ipv6):

Per-Family Fields

• response.families.<family>.reachable — that family's connectivity; both must be reachable for the overall check to pass (AND rule)
• response.families.<family>.time_ms — that family's average round-trip time in milliseconds (a flat number, not a min/avg/max object)
• response.families.<family>.ip — the IP address that family resolved and pinged
• response.families.<family>.error — error detail when that family failed; absent/null on success

There is no per-family packet-loss field — response.families.<family>.packet_loss does not exist. Packet loss is reported only at the top level (response.packet_loss), which in "both" mode mirrors the primary (IPv4) family.

Per-Family Assertions

Configure assertions against either family independently:

Example Scenario: AAAA Rollout

When rolling out IPv6 (AAAA DNS record), use "both" mode to detect IPv6-specific network problems without alarming IPv4 users:

1. Create a duplicate ping check with address family set to "IPv6 Only"
2. Configure alerts only on the IPv6 check
3. As IPv6 network stability is proven, migrate the main check to "Both" mode
4. Now both families are monitored, with visibility into per-family network problems:
   • IPv4 packet loss? — Only the IPv4 family shows degradation
   • IPv6 latency spikes? — Only the IPv6 family shows high RTT
   • Both healthy? — Green across the board

This prevents disrupting IPv4 monitoring when introducing a new IPv6 infrastructure path.

Metrics and Results

Availability Status

Up (Reachable) — At least one packet received response. Displayed with green indicator. Response time data available.

Down (Unreachable) — All packets lost or timed out. Displayed with red indicator. Error information provided.

Response Time Metrics

Minimum RTT — Fastest packet round-trip time. Indicates best-case latency.

Average RTT — Mean of all packet round-trip times. Primary performance indicator.

Maximum RTT — Slowest packet round-trip time. Indicates worst-case latency.

Units: Milliseconds (ms)

On the service's detail page, min/avg/max are visualized per time bucket as a floating band — see Latency Range in Service Details.

Packet Loss

Calculation:

Packet Loss % = (Packets Lost / Packets Sent) × 100

Interpretation:

• 0%: Perfect connectivity
• 1–5%: Acceptable for most use cases
• 5–20%: Degraded network quality
• >20%: Significant network issues
• 100%: Complete loss (host unreachable)

Example Configurations

Monitoring Production Server

Service Name: Production Database Server
IP Address: 192.168.1.100
Project: Production Infrastructure
Enabled: Yes
Check Interval: 60 s (1 min)   # requires Pro plan or higher

Monitoring External Service

Service Name: DNS Server - Google
IP Address: 8.8.8.8
Project: External Dependencies
Enabled: Yes
Check Interval: 300 s (5 min)

Monitoring via Domain

Service Name: Application Server
IP Address: app-server.example.com
Project: Application Servers
Enabled: Yes
Check Interval: 180 s (3 min)

Monitoring IPv6 Host

Service Name: IPv6 Test Server
IP Address: 2001:db8::1
Project: Network Testing
Enabled: Yes
Check Interval: 600 s (10 min)

Network Considerations

Firewall Rules

PING monitoring requires ICMP packets to reach the target:

Outbound Rules — Probers must send ICMP echo requests. Usually permitted by default.

Inbound Rules — Target must accept ICMP echo requests. Target must be able to send echo replies. May be blocked by firewalls/security groups.

Common Firewall Issues:

• ICMP blocked by host firewall
• Network firewall filtering ICMP
• Cloud provider security groups
• Router ACLs blocking ICMP

Solutions:

• Configure firewall to allow ICMP
• Create security group rules
• Use HTTP monitoring as alternative
• Contact network administrator

DNS Resolution

When using domain names:

Resolution Process:

1. Prober resolves domain to IP address
2. PING check targets resolved IP
3. Resolution occurs for each check
4. Both IPv4 and IPv6 may be resolved

DNS Considerations:

• DNS failures cause check failures
• Resolution time included in check duration
• Multiple IPs may exist (A records)
• IPv4 preferred over IPv6 (implementation)

Network Path

PING results reflect the entire network path:

Path Elements:

• Local network latency
• ISP connection
• Internet routing
• Target network
• Target host processing

Latency Sources:

• Geographic distance
• Network congestion
• Routing inefficiencies
• Processing delays

Monitoring Best Practices

Check Intervals

Intervals are in seconds. The minimum allowed depends on your plan (Free: 300 s, Pro: 60 s, Team: 30 s, Enterprise: 10 s).

Critical Infrastructure — 30–120 s. Team/Enterprise plans recommended.

Standard Monitoring — 180–300 s. Good balance for most services.

Basic Availability — 600–1800 s. Periodic checks for non-critical targets.

Target Selection

Monitor:

• Production servers
• Critical infrastructure
• Network gateways
• Load balancers
• DNS servers

Avoid:

• Rate-limited hosts
• ICMP-restricted networks
• Hosts explicitly blocking PING
• Shared hosting environments

Naming Conventions

Include relevant information in service names:

Good Examples:
- DB Server Primary - 192.168.1.100
- Router Gateway - 10.0.0.1
- DNS Server (CloudFlare) - 1.1.1.1

Poor Examples:
- Server 1
- 192.168.1.100
- Ping Test

Complementary Monitoring

Combine PING with HTTP monitoring:

PING: Network layer availability HTTP: Application layer functionality

Example strategy:

• PING monitors server reachability
• HTTP monitors web service functionality
• Both provide complete visibility

Interpreting Results

Consistent Low Latency

Indicates:

• Stable network connection
• Healthy infrastructure
• Optimal routing
• Good connectivity

Typical Values:

• Same datacenter: <1ms
• Same city: 1–10ms
• Same country: 10–50ms
• Different continents: 50–200ms

Intermittent Packet Loss

Possible Causes:

• Network congestion
• Routing changes
• Bandwidth saturation
• Hardware issues

Action Items:

• Monitor trends over time
• Check for patterns
• Investigate during peak times
• Review network infrastructure

High Latency Spikes

Possible Causes:

• Network congestion
• Routing issues
• DDoS attack
• Resource saturation

Action Items:

• Verify with multiple checks
• Check target system load
• Review network status
• Investigate routing path

Complete Failures

Possible Causes:

• Host offline
• Network outage
• Firewall blocking ICMP
• DNS resolution failure

Action Items:

• Verify host status
• Check firewall rules
• Test DNS resolution
• Verify network connectivity

Troubleshooting

Host Unreachable

Symptoms:

• 100% packet loss
• "Host unreachable" error
• No response received

Diagnosis:

1. Verify IP address/domain correct
2. Check host is powered on
3. Verify network connectivity
4. Test from different network
5. Check firewall rules

Solutions:

• Correct IP address if wrong
• Start host if offline
• Fix network configuration
• Allow ICMP through firewall

Request Timeout

Symptoms:

• Intermittent or complete packet loss
• Timeout errors
• High response times

Diagnosis:

1. Check network latency
2. Verify host load
3. Review firewall rules
4. Test during different times

Solutions:

• Investigate network path
• Optimize host performance
• Adjust firewall rules
• Consider longer intervals

DNS Resolution Failures

Symptoms:

• "Could not resolve hostname" error
• Intermittent failures
• Domain-specific issues

Diagnosis:

1. Test DNS resolution manually
2. Try with IP address instead
3. Check DNS server status
4. Verify domain exists

Solutions:

• Use IP address directly
• Fix DNS configuration
• Wait for DNS propagation
• Verify domain validity

Permission Denied

Symptoms:

• "Permission denied" error
• ICMP send failures
• Platform-specific errors

Cause:

Raw socket access may require elevated permissions (implementation-dependent).

Solution:

This is a platform/prober configuration issue. Probers are configured with appropriate permissions.

IPv4 vs IPv6

IPv4 Monitoring

Format: 192.168.1.1. Address Space: Limited (exhausted). Prevalence: Universal support.

Use When:

• Monitoring IPv4-only infrastructure
• Maximum compatibility required
• Legacy systems

IPv6 Monitoring

Format: 2001:db8::1. Address Space: Virtually unlimited. Prevalence: Growing adoption.

Use When:

• Monitoring IPv6-enabled infrastructure
• Future-proofing monitoring
• Testing IPv6 deployment

Dual-Stack Monitoring

For hosts with both IPv4 and IPv6, create two separate monitoring services:

Service 1:
Name: Web Server (IPv4)
IP: 192.0.2.1

Service 2:
Name: Web Server (IPv6)
IP: 2001:db8::1

Limitations

Current Limitations

• No customization of packet count
• Fixed packet size
• No packet payload customization
• Single ICMP type (echo request)

Protocol Limitations

• Cannot verify application status
• May be blocked by security policies
• Limited diagnostic information
• No content validation

Alternative Approaches

When PING is blocked:

• Use HTTP monitoring instead
• Monitor on alternate port
• Use TCP-based connectivity checks
• Coordinate with network team

Related Documentation

• Service Details
• Services Management
• HTTP Monitoring
• Creating First Service
• Global Probes