Incidents

An incident represents a period during which a service is considered to be in a degraded or down state. Incidents are the primary unit of accountability for outages — they have a start time, an optional resolution time, and a history of associated check results.

How an incident is opened

UptimeHunt uses an alert engine that continuously evaluates incoming check results against a service's expectations. The model is deliberately simple: each check result either passes or fails — there is no per-probe confidence scoring or weighting. When a failure arrives, an automatic confirmation burst dispatches extra, independent probes within seconds to confirm or refute it.

An incident opens when enough independent probe locations are failing at once (Failing locations needed, the min_independent_vantages field — default 2, so an isolated probe blip never opens an incident by itself) and the failure has lasted the service's configured Wait before opening period (confirmation_period — default 0, so the burst's verdict opens the incident immediately). Closing works the same way in reverse: once healthy results are confirmed, the incident closes after the Wait before closing period (recovery_period — default 0). All three are per-service settings — see Configuring Alert Rules.

This is why a single probe failing from one location, while every other probe reports success, is treated very differently from all probes failing at once: the former doesn't reach the failing-locations threshold on its own, the latter does within seconds.

Incident severity

Each incident records the service state that triggered it, derived from which expectations failed and how the failing probes were clustered:

• Down — a global-scope failure: the service is unreachable or returned a hard error from across the probe fleet.
• Degraded — a narrower-scope problem (a single region or ISP), or a failure of only soft assertions (for example, response time exceeded its threshold while the service still responded).

Whether an incident is still open or has closed is tracked separately by its resolution time — it is not a third state.

Alerts and notifications

When an incident opens, UptimeHunt fires an alert through every enabled integration (Slack, PagerDuty, email, webhook, etc.). The alert message includes the service name, incident type (Down/Degraded), affected probe locations, and a link to the service details page.

When the incident resolves, a recovery notification is sent through the same integrations.

Resolving an incident

Incidents resolve automatically: the alert engine closes an incident the moment it receives a passing check result that crosses the recovery threshold. There is no manual acknowledge or resolve step in UptimeHunt — a service is either failing its expectations or it isn't, and the incident record follows that state without anyone having to close it out.

If you need to track who is responding to an outage, assign it, or acknowledge it for an on-call rotation, do that in a dedicated on-call tool (UptimeHunt integrates with PagerDuty and Opsgenie, among others) — UptimeHunt's own job is detecting and reporting the outage, not managing the response to it.

After resolution, if the service fails again, a new incident is opened.

Viewing incidents

The Incidents list (accessible from the main navigation) shows all current and past incidents for your organization's services, with start/end times, duration, and the triggering service. Individual service details pages also show per-service incident history.

Related

• How Detection Works — the confirmation-burst and corroboration ladder that feeds this decision
• Expectations — the assertions that define failure
• Alerting & Integrations — where incident notifications go
• Service Details — per-service check history and incidents
• API: Services — programmatic access to incidents