Expectations
Per-service assertions that define what a healthy check result looks like, and how they drive incident detection.
Expectations
Expectations are per-service assertions that define what a healthy check result looks like. Every service has a set of expectations; the alert engine evaluates each incoming check result against them to decide whether the result is passing or failing.
What an expectation asserts
An expectation is a named assertion with an operator and a value. Examples:
| Assertion type | Check type | Passes when |
|---|---|---|
http_status | HTTP | The response status code is in the given set (e.g. [200, 201, 204]) |
body | HTTP | The response body contains the given text |
response_time_ms | HTTP | The check completed under the given millisecond limit |
tls_expiry_days | HTTP | The TLS certificate has at least the given days left |
packet_loss_lt | Ping | Packet loss is below the given percentage |
rtt_lt | Ping | Average round-trip time is below the given millisecond limit |
The available assertion types depend on the check type. Beyond HTTP and Ping, UptimeHunt also ships DNS, SMTP, SSH, and game-server checks, each with its own assertions (for example dns_record, smtp_starttls, ssh_hostkey_fingerprint, gameserver_min_players). The complete, authoritative catalogue per check type is served by the GET /check-types endpoint.
Default expectations
When you create a service, UptimeHunt applies a sensible default expectation set for the check type:
- HTTP — any
2xxstatus code is healthy. - Ping — the host must respond (effectively zero packet loss).
You can replace or augment these defaults in Settings → Services → [service] → Expectations.
Changing expectations
Expectations are versioned. When you save a new expectation set, UptimeHunt creates a new expectation version with a timestamp. The alert engine uses the expectation version that was active at the time each check ran, so historical incident analysis reflects the rules that were in effect, not the current ones.
You can view and restore previous expectation versions from the service's Expectations history.
Expectations and incidents
A check result fails when it violates one or more expectations. The alert engine accumulates failures across consecutive results and opens an incident once the failure threshold is crossed. Which expectations failed is recorded in the incident and surfaced in alert notifications.
Expectations and geographic scope
Expectations carry a locations overlay that controls which probes count toward a service's state. Each probe region or country is either:
- Monitor (the default) — failures from these probes can open or escalate an incident.
- Informational — these probes still run the check and their results are visible in the UI, but they are excluded from the alerting decision.
For example, if a service is only meant to be reachable from Europe, you can mark probes outside Europe as informational — you still see their results, but a failure there will not page you. The overlay matches by probe region or by ISO country code and is enforced both when the expectation is saved and on every result by the alert engine.
Related
- Incidents — how expectation failures become incidents
- Checks — what expectation assertions evaluate
- API: Services — managing expectations via the API