Monitor Intervals and Regions

Check intervals and monitoring regions are fundamental to effective uptime monitoring. This guide explains how to choose the right settings for your monitors and understand plan-based limits.

Check Intervals

Check intervals determine how often Pingara tests your URL.

Available Intervals

Plan Limits

Different Pingara plans have different minimum check intervals:

Free Plan:

• Minimum interval: 5 minutes
• Best for: Personal projects, blogs, staging environments

Pro Plan:

• Minimum interval: 30 seconds
• Best for: Production services, SLA-backed APIs, customer-facing applications

Note: Faster intervals consume more resources and provide earlier failure detection. Choose based on how quickly you need to know about outages.

Choosing the Right Interval

30 seconds (Pro only):

• ✅ Critical payment APIs
• ✅ High-traffic customer-facing services
• ✅ Services with strict SLA requirements (<5 minutes)
• ❌ Internal admin panels
• ❌ Low-priority staging environments

1 minute (Pro only):

• ✅ Production web applications
• ✅ User-facing APIs
• ✅ E-commerce sites
• ✅ Services with moderate SLA requirements

5 minutes (Free & Pro):

• ✅ Company websites
• ✅ Marketing landing pages
• ✅ Internal tools
• ✅ Non-critical APIs
• ✅ Personal projects

10–60 minutes:

• ✅ Batch processing endpoints
• ✅ Scheduled report generators
• ✅ Archival systems
• ✅ Services that only run periodically

Interval vs Detection Time

Detection time = How long before an incident is confirmed.

Pingara requires 2 consecutive failures in the same region before that region votes the monitor down, so detection time is roughly 2× your check interval, not 1×. (With multiple regions, the transition also needs quorum across regions before it's confirmed; see Understanding Incidents for how quorum combines with this per-region rule.)

The clock starts when your service actually breaks, not at the first failed check. In the worst case a check has just run and passed, so you wait a full interval before the first failure even happens, and another before the second.

Example with 30-second interval:

12:00:00 → Check #0 passes, then the service goes down
12:00:30 → Check #1 fails
12:01:00 → Check #2 fails → region votes down

Total detection time: ~1 minute

Example with 1-minute interval:

12:00 → Check #0 passes, then the service goes down
12:01 → Check #1 fails
12:02 → Check #2 fails → region votes down

Total detection time: ~2 minutes

Example with 5-minute interval:

12:00 → Check #0 passes, then the service goes down
12:05 → Check #1 fails
12:10 → Check #2 fails → region votes down

Total detection time: ~10 minutes

Trade-off:

• Faster intervals = Earlier detection + More checks
• Slower intervals = Delayed detection + Fewer checks

For production services, use the fastest interval your plan allows.

Monitoring Regions

Pingara checks your monitors from multiple geographic regions to ensure global reliability.

Available Regions

Pingara operates monitoring probes in:

• 🇺🇸 US East (N. Virginia) - us-east-1
• 🇺🇸 US West (Oregon) - us-west-2
• 🇮🇪 Europe (Ireland) - eu-west-1
• 🇸🇬 Asia Pacific (Singapore) - ap-southeast-1

Plan Limits

Free Plan:

• Regions per monitor: 1, and you choose which of the four
• On the create and edit forms, Monitoring region is a single-choice list of the four regions
• A new monitor starts with a region already selected. Change it to the region closest to your users or infrastructure if that suits you better
• Duplicating a monitor keeps the source monitor's region

Pro Plan:

• Regions per monitor: all 4 regions
• Enable multi-region monitoring for comprehensive coverage

Why Multi-Region Monitoring Matters

Single-region monitoring risks:

• ❌ False positives from regional network issues
• ❌ Can't detect regional outages
• ❌ No insight into global performance
• ❌ Users in other regions might experience issues you don't see

Multi-region monitoring benefits:

• ✅ Detects true global outages vs. regional issues
• ✅ Reduces false alerts (quorum-based failure detection)
• ✅ Shows performance differences by geography
• ✅ Validates CDN and global load balancer behavior

Quorum Rules (Multi-Region)

When monitoring from multiple regions, Pingara uses quorum logic to prevent false positives:

Example with 4 regions enabled:

Scenario 1: Transient network blip
US East:  ✅ Pass
US West:  ❌ Fail (temporary routing issue)
EU West:  ✅ Pass
AP South: ✅ Pass

Result: Monitor stays UP
Reason: Only 1 of 4 regions failed

Scenario 2: Confirmed outage
US East:  ❌ Fail
US West:  ❌ Fail
EU West:  ✅ Pass
AP South: ✅ Pass

Result: Monitor marked DOWN
Reason: 2 of 4 regions failed → quorum reached

Quorum threshold:

With 4 regions enabled, quorum is 2, which is half the regions, not a majority and not all of them. The general rule Pingara uses is: 1 region needs no agreement, and 2 or more regions need at least half to agree, rounded up, with a floor of 2. For the region counts Pingara actually offers, that works out to:

A region only casts a down vote after 2 consecutive failed (or recovered) checks of its own. See Understanding Incidents for how that combines with the region-level quorum above, and for the one exception, the degraded vote.

Pro Tip: Multi-region monitoring dramatically reduces false alerts caused by temporary network issues, ISP routing problems, or regional cloud outages.

Choosing Regions

If you can only pick 1 region (Free plan):

A new monitor starts with a region already selected. That is a starting point, so choose the region closest to your infrastructure or primary users:

• Hosting in AWS us-east-1 → Select US East
• European customers → Select Europe
• Global CDN → Select where your origin server is located

If you can enable all regions (Pro plan):

Enable all 4 regions for:

• Maximum reliability
• Geographic performance insights
• Quorum-based false positive reduction
• Validation of global CDN behavior

Regional Performance Differences

Multi-region monitoring reveals performance by geography:

Example:

US East:  120ms avg response time
US West:  140ms
EU West:  350ms (cross-Atlantic)
AP South: 450ms (cross-Pacific)

Insights:

• Your server is US-based (low latency in US, high in Asia)
• EU/AP users experience slower performance
• Consider a CDN or multi-region deployment

Dashboard view:

Pingara's per-monitor detail page shows latency by region (Pro feature), helping you identify:

• CDN misconfigurations
• Routing inefficiencies
• Regional server issues

Practical Scenarios

Scenario 1: Free Plan Startup

Setup:

• 1 monitor (your production API)
• Interval: 5 minutes
• Region: US East (your server's region)

Why:

• Free plan limit = 1 monitor, 5m minimum interval, 1 region
• Monitors the most critical service
• Fastest detection within plan limits

Upgrade when:

• You need faster detection (<5 minutes)
• You want to monitor multiple services
• Global users experience issues you don't see

Scenario 2: Pro Plan SaaS Application

Setup:

• 5 monitors (app, API, database proxy, status page, docs site)
• Interval: 1 minute for app/API, 5 minutes for others
• Regions: All 4 enabled for app/API, US East only for internal services

Why:

• Pro plan = 30s minimum, all 4 regions, 50 monitors
• Critical services get fast checks + multi-region validation
• Non-critical services use slower intervals to reduce noise
• Quorum logic prevents false alerts from transient issues

Scenario 3: Global E-Commerce Site

Setup:

• 1 monitor (checkout API)
• Interval: 30 seconds
• Regions: All 4 enabled

Why:

• Revenue-critical endpoint needs fastest detection
• Global customer base requires multi-region monitoring
• 30s interval = ~1 minute incident detection time (2 consecutive failures per region)
• Quorum reduces false positives during network blips

Monitoring Costs by Interval

More frequent checks = More data points = More precise monitoring.

Checks per day by interval:

Pingara plans include all checks, with no per-check fees.

• Free: 1 monitor × 5m interval × 1 region = 288 checks/day
• Pro: Up to 50 monitors × 30s interval × 4 regions = Up to 11,520 checks/day per monitor

Advanced Patterns

Different Intervals for Different Monitors

Not every service needs the same monitoring cadence:

Production API (critical):

• Interval: 30 seconds
• Regions: All 4

Admin Dashboard (internal):

• Interval: 10 minutes
• Regions: US East only

Scheduled Batch Job:

• Interval: 60 minutes
• Regions: US East only

Rationale: Prioritize fast detection for user-facing services, relaxed monitoring for internal tools.

Combining Intervals and Alert Policies

You can use alert policies to control notification frequency:

Monitor settings:

• Interval: 30 seconds (fast detection)

Alert policy:

• Notify after 2 consecutive failures (1 minute)
• Repeat alert every 15 minutes if still down

Result: Fast detection, but controlled alert frequency to avoid notification spam.

Regional Failover Validation

If you have regional failover (e.g., AWS multi-region with Route 53):

Setup:

• Monitor: Your DNS name (e.g., api.example.com)
• Interval: 1 minute
• Regions: All 4

Benefit: When one region fails, Route 53 should route requests to a healthy region. Multi-region monitoring verifies that all regions can access your service after failover.

Troubleshooting

"My monitor shows UP in some regions, DOWN in others"

Possible causes:

1. Regional outage - Your infrastructure failed in specific regions
2. Geo-blocking - Firewall blocking certain IP ranges
3. CDN misconfiguration - Some POPs not serving your content
4. DNS issues - Regional DNS servers returning different IPs

Action: Click the monitor → View check results by region → Identify which regions fail

"I'm getting false alerts even with multi-region monitoring"

Possible causes:

1. Intermittent failures - Service flapping between up/down
2. Timeout too short - Service slow but not down
3. Apdex threshold too strict - Marking as degraded too aggressively

Actions:

• Increase timeout if checks are timing out
• Adjust Apdex threshold if performance variance is normal
• Check for server-side resource exhaustion

"My Free plan monitor doesn't catch regional issues"

Limitation: Free plan allows 1 region per monitor. You can choose which of the four, and change it at any time by editing the monitor.

Workaround: Choose the region most critical to your business, rather than keeping the one that was selected for you:

• If 80% of users are in Europe, monitor from EU West
• If infrastructure is in US East, monitor from US East

Long-term solution: Upgrade to Pro for multi-region monitoring.

Best Practices

✅ Use the fastest interval your plan allows for production services

✅ Enable all regions (Pro) for customer-facing applications

✅ Use slower intervals for non-critical services to reduce noise

✅ Monitor from the region closest to your users (Free plan)

✅ Combine fast intervals with controlled alert policies

✅ Review regional performance data monthly to identify trends

❌ Don't use 30s intervals for services that only run hourly

❌ Don't enable all regions for internal-only services (wastes checks)

❌ Don't use 60m intervals for revenue-critical APIs

Next Steps

• HTTP/HTTPS Monitoring - Configure monitor settings
• Apdex Scoring - Understand performance thresholds
• Plans and Pricing - Compare Free vs Pro features
• Setting Up Alerts - Configure notification policies