Ping (ICMP) Monitoring

Ping monitoring tests network-level reachability using ICMP echo requests. It's faster than HTTP and useful for non-web services.

Note: Ping monitoring is a Pro-only feature.

What Is Ping Monitoring?

Ping sends ICMP Echo Request packets to your host and waits for Echo Reply packets.

What it measures:

• Reachability — Is the host online?
• Latency — Round-trip time in milliseconds
• Packet Loss — Percentage of packets that didn't return

What it doesn't measure:

• HTTP status codes
• SSL certificates
• Response content
• Application-level availability

When to Use Ping

✅ Use Ping For:

Network devices:

• Routers
• Switches
• Firewalls
• Load balancers

Non-HTTP services:

• SSH servers
• Database servers
• Game servers
• VPN endpoints

Network-level diagnostics:

• ISP uptime
• Data center connectivity
• WAN link availability

❌ Don't Use Ping For:

Web applications: Use HTTP monitoring instead — it validates actual application availability, not just network reachability.

APIs: Use HTTP monitoring — ping can't validate API responses or status codes.

HTTPS endpoints: Use HTTP monitoring — ping doesn't test SSL or application layer.

Ping vs HTTP Monitoring

Example scenario:

Your web server might:

• ✅ Respond to ping (host is up)
• ❌ Fail HTTP checks (web service is down)

Always use HTTP for web applications.

How Ping Monitoring Works

Check Process

1. Pingara sends ICMP Echo Request to your host
2. Host responds with Echo Reply (if reachable)
3. Pingara records latency and packet loss
4. Check marked as "Up" if packets return

Metrics Collected

ICMP Success: Did any packets return?

• true = Host reachable
• false = All packets lost (host down or ICMP blocked)

ICMP Latency: Round-trip time in milliseconds

• Median of multiple pings (typically 3-5 probes)

Packet Loss: Percentage of packets that didn't return

• 0% = Perfect
• 1-10% = Some issues

• 10% = Significant problems

• 100% = Host unreachable

Interpreting Results

Healthy Ping Monitor

Status: Up
ICMP Success: true
Latency: 25ms
Packet Loss: 0%

Intermittent Issues

Status: Degraded
ICMP Success: true
Latency: 150ms (normally 25ms)
Packet Loss: 15%

Possible causes:

• Network congestion
• Route flapping
• ISP issues

Complete Failure

Status: Down
ICMP Success: false
Packet Loss: 100%

Possible causes:

• Host is offline
• Firewall blocking ICMP
• Network outage

Configuration

Host Format

Enter hostname or IP address:

• ✅ example.com
• ✅ 192.0.2.1
• ✅ 2001:db8::1 (IPv6)
• ❌ https://example.com (no protocol)

Security restrictions:

• Private IPs blocked (127.x, 10.x, 192.168.x)
• Localhost blocked

Check Interval

Same as HTTP monitors:

• 30 seconds (fastest)
• 1 minute
• 5 minutes
• 10 minutes
• 30 minutes
• 60 minutes

Recommendation: Use shorter intervals for critical network infrastructure (30s-1m).

Timeout

Default: 10 seconds

Increase if monitoring geographically distant hosts.

Regions

Same as HTTP:

• US East (N. Virginia)
• US West (Oregon)
• Europe (Ireland)
• Asia Pacific (Singapore)

Multi-region ping helps detect:

• Regional network outages
• Routing issues
• DDoS attacks affecting specific regions

ICMP Firewall Considerations

Why Ping Might Fail

Many organizations block ICMP for security:

• Firewall rules drop ICMP packets
• Host firewall blocks ping
• Cloud provider blocks ICMP by default

If your ping monitors always show 100% packet loss:

1. Verify ICMP is allowed through firewalls
2. Test manually: ping your-host.com
3. Use HTTP monitoring instead

Allowing ICMP

AWS Security Groups:

Type: Custom ICMP - IPv4
Protocol: Echo Request
Port Range: N/A
Source: 0.0.0.0/0

iptables:

iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

Windows Firewall: Enable "File and Printer Sharing (Echo Request - ICMPv4-In)"

When Incidents Are Created

Same logic as HTTP monitors:

2 consecutive failures = Incident created

Example:

1. First ping timeout → Monitor stays "Up"
2. Second consecutive timeout → Status changes to "Down"
3. Incident created, alerts fire

2 consecutive successes = Incident resolved

Apdex Scoring with Ping

Apdex applies to ping latency:

If Apdex threshold = 50ms:

• Satisfied: ≤50ms
• Tolerating: 51-200ms (4 × 50ms)
• Frustrated: >200ms

Degraded status: If latency consistently exceeds threshold.

Combining Ping and HTTP

Monitor the same host with both:

Scenario 1: Both Up

• Network: ✅ Reachable
• Application: ✅ Responding

Scenario 2: Ping Up, HTTP Down

• Network: ✅ Reachable
• Application: ❌ Service crashed

Root cause: Application issue, not network.

Scenario 3: Both Down

• Network: ❌ Unreachable
• Application: ❌ Can't reach

Root cause: Network outage or host down.

Best Practices

Use Ping For Network Devices

Monitor critical infrastructure:

Router: 192.168.1.1
Primary Switch: 10.0.1.1
Backup Gateway: 10.0.2.1

Use HTTP For Web Services

Monitor applications at application layer:

Website: https://example.com
API: https://api.example.com/health

Enable Multi-Region

Detect regional routing issues:

• Ping succeeds from US regions
• Ping fails from EU region
• Possible: Peering issue or regional firewall

Set Realistic Apdex

Local network: 1-10ms Same country: 10-50ms Cross-continent: 50-200ms

Don't set 50ms Apdex for a host in Singapore if you're checking from US East.

Troubleshooting

"100% packet loss"

Check:

1. Is ICMP allowed through firewalls?
2. Test manually: ping your-host.com
3. Is the host actually down?

Fix:

• Allow ICMP in firewall rules
• Enable ping response on host
• Use HTTP monitoring if ICMP not available

"High latency"

Normal causes:

• Geographic distance (US to Asia = 150-250ms)
• Network congestion
• ISP routing

Abnormal causes:

• CPU overload on host
• Network equipment failure
• DDoS attack

"Intermittent packet loss"

Causes:

• Overloaded router
• Faulty network cable
• Wireless interference
• Rate limiting

Next Steps

• HTTP/HTTPS Monitoring — Application-layer checks
• Monitor Intervals and Regions — Scheduling
• Setting Up Alerts — Get notified