Monitors
How PingGuard checks your endpoints from multiple regions and determines their status.
How monitoring works
PingGuard runs independent probe nodes in three global regions: US East (New York), EU West (Amsterdam), and Asia Pacific (Singapore). Each probe executes HTTP(S) checks on a recurring schedule and writes results directly to the database.
There is no central orchestrator. Each probe independently queries the database for monitors due for a check in its region, executes the request, and records the result. This architecture means a single probe failure never prevents monitoring — the other two regions continue checking.
Check execution
- Probe queries for monitors due in its region
- Adds random jitter (0-5s) to prevent thundering herd
- Sends HTTP request via undici (5s default timeout)
- Records status code, response time, and up/down determination
- Batch-inserts buffered results every 10 seconds
Creating and configuring monitors
Create a monitor from your dashboard by providing the URL you want to check. All configuration options:
| Setting | Default | Description |
|---|---|---|
| URL | Required | The HTTP(S) endpoint to check |
| Name | Required | Friendly label for your dashboard |
| HTTP Method | GET | GET, POST, HEAD, PUT, DELETE, PATCH |
| Expected Status | 200 | HTTP status code to consider 'up' |
| Timeout | 5000ms | Maximum wait time before marking as failed |
| Keyword Check | None | Verify a substring exists in the response body |
| Custom Headers | None | JSON headers sent with each request |
| Regions | All 3 | US East, EU West, Asia Pacific |
Understanding status
Each monitor has a status derived from the quorum-based alert evaluation that runs every 60 seconds:
Up
All regions report the endpoint as reachable and returning the expected status code.
Down
At least 2 of 3 regions confirm the endpoint is unreachable or returning errors. Consecutive checks are required — a single failure is not enough.
Degraded
One region is reporting failures but the quorum threshold has not been met. This may indicate a regional issue rather than a full outage.
Unknown
No check results have been recorded yet. This is the initial state for new monitors.
Paused
The monitor has been manually paused. No checks are executed and no alerts fire.
Keyword checks
A keyword check verifies that a specific string appears in the response body. This is useful for detecting cases where a server returns a 200 status code but serves an error page, maintenance notice, or cached stale content.
Example
If your homepage should always contain Welcome to MyApp, set that as your keyword check. If a deploy accidentally breaks the page and it returns a blank 200 response, PingGuard will correctly flag it as down.
The check is a simple substring match (case-sensitive) against the full response body. Keep keywords short and unique to avoid false negatives from minor content changes.
Custom headers
Custom headers let you monitor authenticated endpoints or APIs that require specific headers. Common use cases:
- API tokens —
Authorization: Bearer <token> - Content type —
Accept: application/json - Custom identifiers — Mark requests so your server can distinguish monitoring traffic from real users
Headers are stored as JSON and sent with every check request. They are encrypted at rest in the database.
Check intervals and plan limits
The minimum check interval depends on your plan:
| Plan | Monitors | Min interval | Regions |
|---|---|---|---|
| Free | 5 | 5 minutes | 3 |
| Pro | 20 | 1 minute | 3 |
| Business | 50 | 30 seconds | 3 |
If you hit your monitor limit, PingGuard will show an upgrade nudge with a direct link to the billing page. See Billing & Plans for full plan details.