Configuring Alert Rules

An alert rule defines when UptimeHunt opens an incident for a service and how long to wait before confirming the failure or recovery. Alert rules control the timing of incident detection, independent of the notification integrations you've configured.

Where to configure alert rules

Alert rules are configured per-service: open the service, click Edit (/services/:id/edit), and use the Alerts & notifications section. Every service has one alert rule, with sensible defaults that require no configuration — but you can adjust the timing to match your team's needs.

Wait before opening

What it does: When a failure is detected, UptimeHunt automatically dispatches extra, independent probes to confirm or refute the failure within seconds. Wait before opening (the confirmation_period field in the API) sets how much extra time the failure must last after that burst confirms it, before officially opening an incident.

Default: 0 seconds (the burst decides immediately)

Use case: A positive wait is useful if you have known maintenance windows or expected temporary outages, and you want a small buffer before alerts fire. For example, a 60-second wait means "only open an incident if the failure persists for a full 60 seconds after it's been confirmed by independent probes."

Most teams leave this at 0 — the burst's corroboration is typically sufficient, and there's no benefit to delaying alerts. Set it to a positive value only if you have a specific reason to wait.

Failing locations needed

What it does: The percentage of your independent probe locations that must be failing at once before an incident opens (the min_independent_vantages field in the API). Locations that always fail together count as one, so the percentage measures genuinely independent evidence from your monitored locations.

Default: 20% — accounts for fleet diversity and regional variation. A service with 10 independent locations needs 2 to fail; one with 42 locations needs 9. A service monitored from a single private location will alert on any failure.

Formula: Required failing locations = ⌈percentage ÷ 100 × eligible locations⌉

The denominator is the set of locations your service runs from (via geographic scope settings) and collapsed to independent locations by the detection engine.

Use case: Leave it at 20% for most services. Lower it (e.g., to 10%) to alert sooner and on smaller outages. Raise it (e.g., to 50%) to alert only on broad outages affecting half your monitoring fleet. The History strip's colours always require two distinct probes — an incident can open while the strip stays green if you lower the percentage enough.

Wait before closing

What it does: When a service recovers, UptimeHunt dispatches a healing burst to confirm that the recovery is real and not a momentary blip. Wait before closing (the recovery_period field in the API) sets how much extra time to wait after that healing burst confirms, before officially closing the incident and sending recovery notifications.

Default: 0 seconds (the burst decides immediately)

Use case: A positive wait protects against false recoveries when a service is intermittently failing. For example, a 120-second wait means "only close the incident if the service stays healthy for a full 120 seconds after recovery is confirmed."

How Incident Detection Works

When a check fails on a service:

1. Automatic burst dispatch — UptimeHunt immediately sends extra probes to independent locations. These probes answer the question: "Is this a real failure, or just a blip from one location?"

2. Confirmation — If enough independent locations are failing (Failing locations needed), the engine waits for the configured Wait before opening period. Once that time has elapsed (or immediately, if set to 0), the incident opens and alerts fire.

3. Healing burst — As soon as healthy results arrive, UptimeHunt dispatches a healing burst to confirm the recovery is real, not a momentary fluctuation.

4. Recovery — If the healing burst confirms healthy results, the engine waits for the configured Wait before closing period. Once that time has elapsed (or immediately, if set to 0), the incident closes and recovery notifications fire.

Why the defaults work for most services

By default, both wait periods are 0 seconds and Failing locations needed is 20% — incidents open and close based on the burst's corroboration alone. This works well because:

• The confirmation burst lands within seconds, not minutes, so waiting for a separate detection event is unnecessary.
• Each burst spans independent probe locations and networks, providing strong evidence of a real problem (not a local network glitch).
• Recovery confirmation works the same way: a burst of healthy results from independent locations is reliable evidence that the service is back up.
• At 20%, the percentage scales naturally with your fleet size. Ten locations need two to fail; forty locations need nine. A single private probe location will alert on any failure.

Adjust these settings only if your service has specific failure patterns — frequent intermittent failures, known maintenance windows, or business-critical recovery requirements that demand extra validation time.

Public status page behavior

An outage seen from a single location is reported as degraded on your public status page and never colours a day red.

Related

• How Detection Works — the automatic confirmation burst and corroboration ladder
• Incidents — incident lifecycle and severity
• Alerting & Integrations — where incident notifications go
• Status Pages — public status page components and visibility