How niceuptime decides up vs down

niceuptime records individual observations first, then derives monitor state from authoritative Heartbeats and the monitor’s policy.

That separation keeps the evidence visible while preventing an incomplete Probe round from changing state.

How Probe rounds become Heartbeats

Each Probe round collects one result from each configured region.

The round becomes authoritative when more than half of the configured regions have reported success, or when enough failures have arrived that the success threshold can no longer be reached.

Until one of those conditions is true, the regional observations remain evidence but the round does not update monitor state.

Once a round is authoritative, niceuptime records its success or failure as the Heartbeat that enters the shared state evaluator.

Older or duplicate rounds do not replace a newer applied round.

How policy thresholds change state

A successful Heartbeat normally produces a healthy state and resets the failure count.

A failed Heartbeat increments the failure count and leaves the monitor late until the configured failure threshold is reached.

At that threshold, the monitor becomes failing and an Incident opens if one is not already open.

Recovery uses its own threshold.

After a failing monitor receives enough consecutive successful Heartbeats, it becomes healthy and the open Incident resolves.

If more successful Heartbeats are still required, the monitor remains recovering so the intermediate state is visible.

Pulse deadlines and grace

A Pulse reports in rather than being run by a Probe worker.

After each Pulse Heartbeat, niceuptime stores the next expected time from the configured interval and adds the configured grace period to form the deadline.

For example, a safe placeholder schedule that reports every five minutes with ninety seconds of grace is not overdue until the stored expected time plus that grace has passed.

When an active Pulse passes that deadline, the deadline sweep moves it to failing through the same state and Incident persistence path.

A later successful Pulse is then evaluated against the recovery threshold before the Incident resolves.

Inspect the evidence

The monitor’s recent checks show the observation source, result, time, and any available region and latency.

History buckets show the success and failure totals used to summarize the selected time range.

Use those observations together with the monitor’s interval, grace, failure threshold, and recovery threshold to understand why the current state changed.