Creating Your First Monitor

This guide walks you through every field in Pingara's monitor creation form so you can configure monitoring exactly how you need it.

Before You Begin

Make sure you have:

• ✅ A verified Pingara account
• ✅ A URL you want to monitor
• ✅ Knowledge of what response codes your URL returns

Plan limits: The Free plan allows 1 monitor with 5-minute minimum check intervals. Upgrade to Pro for 50 monitors and 30-second intervals.

Creating a Monitor

1. Open the Monitor Form

From your dashboard:

1. Click "Add Monitor" in the top right
2. The monitor creation form opens

2. Monitor Type

Choose between:

HTTP/HTTPS (most common)

• Monitors web pages, APIs, and web services
• Measures full HTTP request/response cycle
• Validates status codes and keywords
• Tracks SSL certificate expiry

Ping (ICMP) (Pro only)

• Network-level reachability test
• Faster than HTTP (no application layer)
• Useful for non-HTTP services
• Measures packet loss

Most users should choose HTTP/HTTPS — it provides more detailed diagnostics.

3. Monitor Name

Best practices:

• Use descriptive names: Production API not Monitor 1
• Include environment: Homepage (Production)
• Use consistent naming: Service - Environment

Examples:

• ✅ Main Website - Production
• ✅ API Gateway - Staging
• ✅ Payment Endpoint - EU Region
• ❌ Test (too vague)

4. URL

Format: Must include protocol

• ✅ https://example.com
• ✅ https://api.example.com/health
• ✅ http://staging.example.com:8080/status
• ❌ example.com (missing protocol)

Security restrictions:

• Private IPs are blocked (127.x, 10.x, 192.168.x)
• Localhost and internal hostnames are blocked
• Only http:// and https:// protocols allowed

Tip: For APIs, monitor your /health or /status endpoint instead of the root path.

5. HTTP Method

Choose the HTTP verb for your check:

• GET — Default, reads data (most common)
• POST — Submits data (Pro only)
• HEAD — Like GET but only fetches headers (faster)

When to use HEAD:

• You only care about availability, not content
• The endpoint returns large responses
• You want faster checks

6. Check Interval

How often Pingara checks your URL:

Choosing an interval:

• Critical services: 30s-1m (requires Pro)
• Standard production: 5m
• Non-critical/staging: 10m-60m

Cost tip: Longer intervals consume fewer checks. If uptime is less critical, use 30m or 60m.

7. Timeout

Maximum time to wait for a response before marking the check as failed.

Default: 30 seconds

When to adjust:

• Slower APIs: Increase to 45-60 seconds
• Fast endpoints: Decrease to 10-20 seconds for earlier failure detection

Warning: Setting timeout too low causes false positives. Most sites should use 20-30 seconds.

8. Monitoring Regions

Choose which geographic regions check your URL.

Available regions:

• 🇺🇸 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: 1 region
• Pro: All 4 regions

Multi-region benefits:

• Reduces false positives (quorum-based alerting)
• Detects regional outages
• Measures geo-distributed performance

How quorum works: When you enable multiple regions, Pingara only marks your monitor as "Down" if 2 or more regions fail simultaneously. This prevents false alerts from transient network issues.

9. Expected Status Codes

Comma-separated list of HTTP status codes considered successful.

Default: 200,201,202,203,204 (2xx success codes)

Common configurations:

For standard web pages:

200

For APIs that return various success codes:

200,201,204

For redirecting URLs:

200,301,302

Tip: If your endpoint returns 301/302 redirects, enable "Follow Redirects" (see below) instead of adding them here.

10. Keyword Check (Optional)

Verify that the response body contains a specific text string.

Use cases:

• Detect "silent failures" (200 OK but error page)
• Verify dynamic content is rendering
• Confirm database connectivity

Examples:

• ✅ "status":"ok" (API health check)
• ✅ Welcome to (homepage is rendering)
• ✅ Version 2.1 (correct version deployed)

How it works:

1. Pingara fetches your URL
2. Searches the response body for the keyword
3. Marks check as failed if keyword is missing (even with 200 OK)

Warning: Keywords are case-sensitive. Use exact matches.

11. SSL Certificate Monitoring

For HTTPS URLs, Pingara automatically tracks SSL certificate expiry.

Default warnings: 30, 14, 7 days before expiry

When you'll be alerted:

• 30 days before expiry (first warning)
• 14 days before expiry (second warning)
• 7 days before expiry (final warning)

Custom thresholds: You can adjust these in the advanced settings (e.g., add 3 days, 1 day for more urgent reminders).

12. Follow Redirects

Enabled by default: Pingara follows up to 10 redirects

When to disable:

• You want to monitor the redirect itself (not the final destination)
• You're debugging redirect chains

Max redirects: Configurable (default: 10)

13. Apdex Threshold

The response time (in milliseconds) considered "satisfactory" for user experience.

Default: 500ms

How it affects scoring:

• ≤ 500ms — Satisfied (counts as 1.0)
• 501-2000ms — Tolerating (counts as 0.5)
• > 2000ms — Frustrated (counts as 0.0)

Choosing a threshold:

• Fast APIs: 100-300ms
• Standard web pages: 500-1000ms
• Slow backends: 1000-2000ms

Learn more about Apdex scoring.

14. Tags (Optional)

Comma-separated labels for organizing monitors.

Examples:

production, critical, api

staging, web, us-region

Use tags to:

• Filter monitors on the dashboard
• Group alerts by service
• Generate reports by environment

15. Environment

Descriptive label for deployment stage.

Common values:

• production
• staging
• development
• qa

After Creating Your Monitor

First Check

Pingara runs the first check within 1 minute. You'll see:

• ✅ Status indicator (Up/Down/Pending)
• ⏱️ Initial response time
• 📊 First data point on latency chart

What Happens Next

Every check interval:

1. Probe fetches your URL from selected regions
2. Records detailed metrics (DNS, TCP, TLS, TTFB, total time)
3. Updates monitor status based on consecutive failures/successes
4. Creates incidents if 2 consecutive failures occur
5. Triggers alerts via configured channels

Editing Your Monitor

Click the monitor name → "Edit" to change:

• Check interval
• Regions
• Timeout
• Status codes
• Keywords

Note: Editing regions resets consecutive failure counters to prevent stale data from triggering false alerts.

Common Configurations

Simple Website Monitoring

Type: HTTP/HTTPS
URL: https://example.com
Method: GET
Interval: 5 minutes
Region: us-east-1
Status Codes: 200
Keyword: (none)

API Health Check

Type: HTTP/HTTPS
URL: https://api.example.com/health
Method: GET
Interval: 1 minute (Pro)
Regions: All 4 (Pro)
Status Codes: 200
Keyword: "status":"healthy"

SSL Expiry Monitoring

Type: HTTP/HTTPS
URL: https://secure.example.com
Method: HEAD
Interval: 60 minutes
Region: us-east-1
SSL Warnings: 30, 14, 7, 3, 1 days

Troubleshooting

"Private IP addresses are not allowed"

You're trying to monitor an internal IP (127.x, 10.x, 192.168.x). Pingara blocks these for security. Use a public hostname instead.

"Monitor always shows as Down"

Check:

• Is the URL publicly accessible?
• Are status codes correct?
• Is the timeout long enough?
• Is the keyword spelled correctly?

"False positives (random Down alerts)"

• Enable multiple regions (Pro) for quorum-based alerting
• Increase timeout if responses are slow
• Check if your server blocks monitoring requests

Next Steps

• HTTP/HTTPS Monitoring — Advanced HTTP features
• Monitor Intervals and Regions — Deep dive into scheduling
• Setting Up Alerts — Get notified when monitors fail
• Apdex Scoring — Optimize your thresholds