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 to create an incident (reduces false positives).

Example with 1-minute interval:

12:00 → Check #1 fails
12:01 → Check #2 fails → INCIDENT CREATED
12:01 → Alert sent

Total detection time: ~1 minute

Example with 5-minute interval:

12:00 → Check #1 fails
12:05 → Check #2 fails → INCIDENT CREATED
12:05 → Alert sent

Total detection time: ~5 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
• Select the region closest to your users or infrastructure

Pro Plan:

• Regions per monitor: Unlimited (all 4 available)
• 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: Real outage
US East:  ❌ Fail
US West:  ❌ Fail
EU West:  ❌ Fail
AP South: ❌ Fail

Result: Monitor marked DOWN
Reason: All regions failed → True outage

Quorum threshold:

• 2+ regions fail → Status changes to DOWN
• 1 region fails → No incident (likely transient)

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):

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, unlimited 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 = ~30s incident detection time
• 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 — 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 only.

Workaround: Choose the region most critical to your business:

• 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