What Is a Probe Node in Uptime Monitoring?

What Is a Probe Node?

A probe node is a server that performs monitoring checks from a specific location.

When an uptime monitoring service checks if your website is available, that check runs from a probe node somewhere in the world.

Probe Node (London) → Your Service
Probe Node (Tokyo) → Your Service
Probe Node (New York) → Your Service

Each probe independently checks your service and reports results.

How Probe Nodes Work

The Check Process

1. Scheduler triggers check at configured interval
2. Probe node connects to your service endpoint
3. Request is sent (HTTP GET, TCP connect, etc.)
4. Response is received (or timeout occurs)
5. Results recorded: status, response time, errors
6. Data sent to central system for analysis and alerting

What Probes Measure

Depending on the check type:

• Availability: Did the service respond?
• Response code: Was it 200 OK or an error?
• Response time: How long did it take?
• Content: Does the response contain expected data?
• SSL certificate: Is it valid and not expiring soon?

Why Location Matters

The Internet Isn't Uniform

A service that works in London might be unreachable from Sydney because:

• Routing issues between regions
• CDN configuration problems
• Regional DNS failures
• Undersea cable problems
• Local ISP issues

Single Location = Blind Spots

If you only monitor from one location:

• You miss regional outages
• You can't verify global availability
• Network issues at the probe look like service outages

Geographic Coverage

For a global service, you want probes in:

• North America
• Europe
• Asia Pacific
• (Optionally) South America, Africa, Middle East

This ensures users worldwide can reach your service.

Multi-Location Monitoring

How It Works

Multiple probes check your service independently:

London    → Service → Success
Singapore → Service → Success
Virginia  → Service → FAILED
São Paulo → Service → Success

What does this mean?

• 3/4 locations succeed
• Problem is likely Virginia network, not your service
• Don't alert—it's probably a probe-side issue

Majority Voting

Common algorithm:

Alert only if majority of locations report failure

This filters out false positives from single-location issues.

Confirmation Checks

Alternative approach:

Alert only if all locations fail, or if failure persists for multiple checks

This requires sustained, global failure before alerting.

Types of Probe Nodes

Public Probes

Run by the monitoring service in data centres worldwide.

Pros:

• No setup required
• Professionally maintained
• Global coverage

Cons:

• Can only check publicly accessible services
• No visibility into internal systems

Private Probes

Run inside your own network.

Pros:

• Monitor internal services
• Test from inside network perimeter
• Verify internal connectivity

Cons:

• Requires setup and maintenance
• Single point of failure if only one

On-Premise Probes

Physical or virtual appliances in your facilities.

Use cases:

• Monitoring private data center services
• Verifying connectivity from office locations
• Compliance requirements

Choosing Probe Locations

Match Your Users

If your users are primarily in Europe, prioritise European probe locations.

If you're global, you need global probes.

Avoid Overlap

Three probes in the same AWS region aren't as useful as probes in three different regions.

Geographic diversity provides better coverage.

Consider Network Paths

Probes in major internet hubs (Frankfurt, Singapore, Virginia) can identify routing issues that affect large portions of traffic.

Minimum Viable Setup

At absolute minimum:

• 3 locations
• On different continents or regions
• From different network providers

Probe Reliability Issues

Probe Node Failures

Probe servers can have problems too:

• Network outages at probe location
• Hardware failures
• Software bugs
• Resource exhaustion

Good monitoring services handle this with:

• Health monitoring of probe nodes
• Automatic failover
• Exclusion of unhealthy probes from alerting logic

Network Issues vs Service Issues

How to tell the difference:

False Positives from Probes

Single-location monitoring generates false positives when:

• Probe's network has issues
• Regional routing problems
• DNS propagation delays
• Temporary congestion

Multi-location monitoring largely solves this.

Probe Timing Considerations

Check Interval

How often probes check your service:

Timeout Settings

How long to wait for response:

• Too short: False failures on slow responses
• Too long: Delayed detection of real problems

Recommendation: 10-30 seconds depending on expected response time.

Staggered vs Simultaneous

Simultaneous: All probes check at the same time

• Better for comparing results
• Spike in traffic to your service

Staggered: Probes check at different times

• Smoother load distribution
• More continuous monitoring

Private Probe Use Cases

Internal Service Monitoring

Services behind firewalls need internal probes:

• Internal APIs
• Database admin interfaces
• Intranet applications

Network Validation

Verify connectivity from:

• Office locations
• Data centers
• Cloud VPCs

End-to-End from Inside

Test the path from:

• Application server to database
• Internal service to external dependency
• VPN endpoint to internal resource

Summary

A probe node is a server that performs health checks from a specific location.

Key concepts:

• Probes check availability, response time, and content
• Location matters—internet connectivity varies by region
• Multi-location monitoring prevents false alerts
• Majority voting filters out single-location issues
• Private probes monitor internal services

Best practices:

• Use at least 3 locations
• Choose geographically diverse probes
• Match probe locations to user locations
• Require multiple failures before alerting
• Consider private probes for internal services

The goal is reliable detection of real problems while avoiding false alarms from probe-side issues.