Concepts
Core concepts behind UptimeHunt — checks, probes, incidents, expectations, and organizations.
Concepts
This section explains the mental model behind UptimeHunt. Read it if you want to understand why things work the way they do, not just how to click through the UI.
Checks
What a check is, how it runs, and what it records.
Probes
The distributed agents that execute checks from multiple locations.
Incidents
How UptimeHunt detects, opens, and resolves incidents.
Expectations
Per-service assertions that define what a healthy check result looks like.
Organizations
Shared workspaces, membership, roles, and how resources are scoped.
The big picture
A service is a thing you want to monitor — a URL, a hostname, or an IP address. Services belong to projects (optional grouping) inside an organization (workspace).
Each service has a check type and a check interval. On schedule, probes — geographically distributed monitoring agents — execute the check and report the result back. Results are stored and displayed per-check in the service details view.
Expectations define what a healthy result looks like for that service (for example, "HTTP status must be 2xx" or "response time under 2 s"). The alert engine evaluates each incoming result against the service's expectations. When a configurable threshold of consecutive failures is reached, the engine opens an incident and fires an alert through the configured integrations (Slack, PagerDuty, email, etc.). When the service recovers, the incident is resolved and a recovery notification is sent.