UptimeHunt Docs
Concepts

Checks

What a check is, how checks are scheduled and executed, what is recorded in each result, and how check intervals affect coverage.

Checks

A check is a single execution of a monitoring test against one service, performed by one probe at one point in time.

Check types

UptimeHunt supports the following check types:

TypeWhat it doesKey result fields
HTTPSends an HTTP/HTTPS request to a URL and validates the responseStatus code, response time, TLS expiry, response body match
PingSends ICMP echo requests to a host or IP addressReachability, round-trip time (min/avg/max), packet loss
DNSResolves a DNS record and validates the answerRecord values, record existence, TTL, record count
SMTPConnects to a mail server and inspects its greetingBanner + code, advertised capabilities, STARTTLS, certificate expiry
SSHReads an SSH server's protocol banner and host key (no login)Banner, software version, host-key fingerprint
Game serverQueries a game server's status protocolResponds, player count, current map, server name, game type

The check type is set when you create a service and cannot be changed afterwards.

How checks are scheduled

Each service has a check interval — the target gap between successive check executions. Intervals are set in seconds. The platform minimum depends on your plan (Free: 300 s, Pro: 60 s, Team: 30 s, Enterprise: 10 s).

Scheduling is handled by the probe. Once a probe receives the service's configuration, it runs the check at the specified interval. Checks are not centrally queued — each probe runs its own schedule, so if you have multiple probes assigned to a service they each run on their own independent timer.

What a check records

Every check result captures:

  • Timestamp — when the check ran (the probe's local time, normalized to UTC).
  • Probe — which probe executed the check (location, country, identifier).
  • Reachable — whether the target responded at all (boolean).
  • Response time — how long the check took from the probe's perspective (milliseconds).
  • Type-specific data — for HTTP: status code, response headers subset, SSL details; for ping: RTT statistics, packet loss.
  • Check result ID — a unique identifier for deduplication (used when a probe reconnects after a disconnect and replays buffered results).

Results are immutable once written. They are stored in MongoDB and visible in the service details view under the Recent Checks tab.

Check identity and deduplication

Each check execution is assigned a stable ID before it runs. If the probe disconnects from the broker mid-flight and reconnects, it replays the buffered result with the same ID — the platform deduplicates on that ID so no result is double-counted.

On-demand checks

You can trigger an off-schedule check via Run Now on the service details page or via the API (POST /api/v1/services/{id}/run). The broker dispatches a command to the probe currently holding an active connection for that service. The result appears in the check history like any scheduled check; it is tagged as an on-demand run.

On-demand is best-effort

If no probe is currently connected for the service, the dispatch returns a 202 with an empty dispatched list — the check does not run. This is not an error; it means there is no live probe link at that moment.

Check intervals and coverage

Choosing a shorter interval gives you faster detection of outages but consumes more check capacity from your plan quota. A rule of thumb:

  • Critical production services — 30–60 s (Team/Enterprise plans).
  • Important but non-critical — 60–300 s.
  • Periodic compliance or low-traffic services — 300–3600 s.

Because each probe runs its own schedule independently, a service checked by N probes at interval T will produce approximately N × (86400 / T) results per day.

On this page