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:

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 — including, for every assertion type, the full set of comparison operators it accepts (equals, one-of, not-one-of, at-least, at-most, under, over, in-range, contains, regex, exists, …), not just one fixed operator. See Expected Results for how the rules builder exposes that set.

Default expectations

When you create a service, UptimeHunt applies a sensible default expectation set for the check type:

• HTTP — any 2xx status code is healthy. New HTTP services also default to following redirects and verifying TLS certificates (see Transport & TLS).
• Ping — the host must respond (effectively zero packet loss).

You can replace or augment these defaults in a service's Expected results section, on its Add/Edit page. The rules builder always shows rows — a brand-new service starts with the check type's built-in rule(s) already listed and tagged default, so there is nothing to "turn on" before you can see what healthy currently means. Editing, adding, or removing a rule switches the whole list to edited; Reset to defaults clears any custom rows and goes back to inheriting the built-in default. See Services Management for the full rules-builder walkthrough, including the operator set, HTTP status classes, regex safety bounds, and the TLS certificate assertions.

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

Where a service runs from is not part of the expectation document — it is the service's own run allowlist (run_regions / run_countries, both empty meaning everywhere). A continent in run_regions is a living set: new probe locations in that continent are adopted automatically. A country in run_countries is a fixed pin. The two are combined with OR, so a service can run from all of Europe plus exactly Japan.

Locations outside the allowlist never run the check at all, so they produce no results to evaluate: expectations always apply to every result the service produces, from every location it runs from. There is no per-location evaluation tier. See Monitoring Locations for the editor.

Related

• Incidents — how expectation failures become incidents
• Checks — what expectation assertions evaluate
• API: Services — managing expectations via the API