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 active monitor with 5-minute minimum check intervals. Paused monitors don't count toward the limit, so you can keep a paused monitor and still create a new one. Upgrade to Pro for 50 monitors and 30-second intervals.

Creating a Monitor

1. Open the Monitor Form

From your dashboard:

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

2. Monitor Type

The form offers six types, none of them plan-gated:

HTTP/HTTPS (most common)

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

Keyword (HTTP + content check)

Same as HTTP/HTTPS, with a required text match against the response body
Catches "silent failures", a 200 OK that's actually an error page

Ping (ICMP)

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

TCP / UDP

TCP opens a real connection to the port; UDP is connectionless, so it sends a probe datagram and reads the reply or the ICMP error the host returns
Useful for databases, mail servers, and other non-HTTP services

DNS record

Queries a DNS record and asserts against the returned value
The url field holds a bare hostname, not a URL, for this type, as it does for Ping and TCP/UDP

WebSocket

Opens a WebSocket connection and, optionally, checks for an expected message

Most users should choose HTTP/HTTPS. It gives you more detail when something goes wrong.

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:

Blocked on every monitor type alike, whether HTTP, ping, TCP, DNS, or WebSocket
Blocks loopback, private, and link-local ranges, for example 127.x, 10.x, 172.16–31.x, 192.168.x, 169.254.x (including the 169.254.169.254 cloud metadata address), and their IPv6 equivalents
Blocks carrier-grade NAT (100.64.x–100.127.x), which covers Tailscale and some carrier and satellite networks
Blocks localhost and hostnames ending .local, .localhost, .internal, or .localdomain
Applies after DNS resolution, so a hostname that resolves to a private address is blocked too, not just a private IP typed directly
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, with a custom request body if you need one
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:

Interval	Free	Pro	Use Case
30 seconds	❌	✅	Critical production services
1 minute	❌	✅	High-traffic applications
5 minutes	✅	✅	Standard production monitoring
10 minutes	✅	✅	Non-critical services
30 minutes	✅	✅	Development/staging
60 minutes	✅	✅	Low-priority endpoints

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 per monitor, and you choose which of the four. A new monitor starts with one already selected. Pick the region nearest your users, either when you create the monitor or when you edit it later.
Pro: All 4 regions

Multi-region benefits:

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

How quorum works: A region votes only after 2 consecutive failed checks (or 2 consecutive successes to vote recovered). Those thresholds are fixed, not configurable. With 2 or more regions selected, quorum requires max(2, ceil(regions / 2)) of them to agree: 2 regions needs both, 3 needs 2, 4 needs 2. A single-region monitor has no one to agree with, so it transitions on its own evidence. This prevents false alerts from a transient issue in one region.

9. Expected Status Codes

The list of HTTP status codes that count as success. Both the New Monitor form and the Edit Monitor form let you set this. A new HTTP monitor's field comes pre-filled with:

200, 201, 202, 203, 204, 301, 302

Enter your own comma-separated list of individual three-digit codes if you want a different one. Ranges aren't accepted, and you can't clear the field to blank on an HTTP monitor. A blank list would be stored as an empty array, which the probe reads as those same seven codes anyway, so a cleared field would quietly keep checking against the pre-filled list while the monitor's detail page showed no codes at all and the Developer API published an empty array. Refusing a blank save keeps one encoding across the whole system, rather than two that happen to agree by coincidence.

You can see the stored list on the monitor's detail page, under Configuration → Expected Status Codes. The v1 Developer API returns it, and a write-scoped key (a Pro feature) can set it on POST and PATCH /monitors.

That list is the dashboard's, not a platform floor: the platform-wide default is any 200-399 status, and an operator can change it in the Ops Console. That default applies only when a monitor is created without the field at all, a path no UI or API takes today.

Tip: 301 and 302 are already in the list above, so a redirecting URL passes as-is. If you'd rather follow the redirect and check what it lands on, enable "Follow Redirects" (see below).

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:

Pingara fetches your URL
Searches the response body for the keyword as a literal substring, never a wildcard or matching language
By default, marks the check as failed if the keyword is missing (even with 200 OK); switch Match mode to "Does not contain" to fail when the keyword is present instead

Match case: Keyword matching is case-sensitive by default. Turn off the Match case toggle if you want a case-insensitive match.

Failure severity: A keyword mismatch marks the check Down by default on existing monitors. Monitors you create from now on default to Degraded instead. You can switch either way in the field itself.

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. Environment

Deployment stage this monitor belongs to. Required. Pick one:

Production
Staging
QA
Development

15. Service (Optional)

Which part of your stack this monitor represents. Pick one:

16. Criticality (Optional)

How much it matters if this monitor goes down. Pick one:

Critical
Important
Non-critical

Service and Criticality show as badges on the monitor list; Environment shows on the monitor detail page instead. All three fields can be used to filter the dashboard down to the monitors you care about.

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:

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

Editing Your Monitor

Click the monitor name → "Edit" to change:

Check interval
Regions
Timeout
Keywords

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

Duplicating a Monitor

Instead of rebuilding a similar monitor field by field, use Duplicate, found in the row menu on the Monitors page or the header menu on a monitor's detail page. It opens the New Monitor form pre-filled with the source monitor's configuration, including its region, and the name pre-set to Copy of <source name>. Change the URL and name, then save like any other monitor.

Three things about the clone are worth knowing before you save it:

It's created paused. You're expected to change the URL before it starts checking. An active clone would immediately burst checks, and possibly alerts, against the same URL as the source. Resume it once the URL points where you want.
Alert rules come with it. The clone pages the same people the source does. If that's not what you want for this monitor, edit or remove the alert rule after duplicating.
Status page membership does not. A clone is usually a new endpoint that shouldn't show up on a public status page until you add it there yourself.

Duplicating isn't gated. It's available on every plan. On Free, creating the paused clone succeeds even at the 1-monitor limit, since paused monitors don't count toward it; you'll hit the limit if you try to resume it, with the usual upgrade prompt.

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"

Pingara blocks loopback, private, and link-local addresses (for example 127.x, 10.x, 172.16–31.x, 192.168.x, 169.254.x), carrier-grade NAT (100.64.x–100.127.x, used by Tailscale and some carrier networks), and internal hostnames like localhost or anything ending .local or .internal. The block applies to every monitor type alike (HTTP, ping, TCP, DNS, and WebSocket).

This check runs after DNS resolution, so a public hostname that resolves to a private address is blocked the same as typing the IP directly. Pointing at a hostname instead doesn't work around it. The target must be reachable from the public internet. If a monitor that used to work suddenly hits this error, check whether its DNS record changed to point somewhere internal; the check result's error type will show ssrf_blocked.

"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