Skip to content

Monitors

Checks a URL and verifies the HTTP status code matches the expected value (default 200).

  • Target: full URL (e.g. https://example.com/health)
  • Expected Status: HTTP status code to expect
  • Keyword: optionally check if the response body contains (or doesn’t contain) a string
  • Keyword Match: exact (default) or regex — when set to regex, the keyword field is treated as a regular expression pattern (e.g. "status":\s*"ok", v\d+\.\d+). The UI shows keyword fields only when the match rule is not “None”.

Checks the SSL certificate of a hostname and alerts before it expires.

  • Target: hostname (e.g. example.com)
  • SSL Warn Days: number of days before expiry to alert (default 30)

Checks whether a TCP or UDP port is open on a host.

  • Target: host:port (e.g. db.example.com:5432)
  • Protocol: tcp (default) or udp
  • TCP checks perform a dial and verify the connection succeeds
  • UDP checks send a probe packet; if no ICMP rejection is received, the port is considered open
  • Use cases: databases (PostgreSQL, MySQL), Redis, DNS servers (UDP), game servers, MQTT brokers

Resolves a DNS record and optionally validates the response value. Useful for DNS propagation checks, MX/SPF/DKIM record monitoring, and catching accidental record changes.

  • Target: hostname to resolve (e.g. example.com)
  • Record Type: A (default), AAAA, MX, TXT, CNAME, NS
  • Expected Value (optional): case-insensitive substring match against any returned record. Monitor fails if the expected value is not found
  • Resolver (optional): custom DNS resolver (e.g. 1.1.1.1 or 8.8.8.8:53). Default uses the system resolver

Example: check that example.com resolves to an IP in the 93.184. range via Cloudflare’s resolver.

Passive monitoring — your service pings Pong instead of Pong checking your service. Useful for cron jobs, background workers, and scheduled tasks.

  • No target needed — Pong generates a unique ping URL
  • If no ping is received within the interval, the monitor goes down

See Heartbeat Monitoring for details.

SettingDescriptionDefault
IntervalHow often to check5 minutes
TimeoutMax wait for response5 seconds
Confirmation CountFailures needed before marking down1
Expected StatusHTTP status code to expect200
ProtocolTCP or UDP (port monitors only)TCP
Keyword Matchexact or regexexact

HTTP and keyword monitors support optional authentication for checking services behind auth. Two methods are available:

  • Basic Auth — sends Authorization: Basic <base64> header with a username and password
  • Custom Header — sends an arbitrary header (e.g. X-API-Key: your-key)

Credentials are encrypted at rest using AES-256-GCM. The ENCRYPTION_KEY environment variable must be configured to use this feature. See Configuration for details.

Credentials are never returned in API responses. The API only indicates whether auth is configured via the http_auth_configured field.

You can trigger an immediate check on any monitor via the API or the “Check Now” button in the UI. This resets the monitor’s check timer so the scheduler picks it up on the next tick (within 1 second).

Terminal window
curl -X POST https://api.getpong.dev/api/v1/monitors/42/check \
-H "Authorization: Bearer pong_your_key"

Returns 202 Accepted with {"status": "queued"}. The result appears in the check results within a few seconds.

You can wipe a monitor’s check result history, alert log, and reset its state (status, consecutive fails, last checked) to start fresh. Useful after fixing a misconfigured monitor or when you want a clean uptime timeline.

Terminal window
curl -X POST https://api.getpong.dev/api/v1/monitors/42/reset \
-H "Authorization: Bearer pong_your_key"

In the UI: open the monitor detail page → “Reset History” button in the Recent Check Results section. Destructive — the UI asks for confirmation.

Returns 200 OK with {"status": "reset"}.

You can pause a monitor to temporarily stop checks without deleting it.

Assign alert contacts to a monitor to be notified on state changes. You can assign multiple contacts to a single monitor.