Alerts & states

CuliPulse is deliberately quiet — it double-checks before telling you something is wrong, so a single slow response or a one-off network blip doesn’t wake you for nothing.

The four states

Up — the check is passing.
Down — the check is failing (unreachable, wrong status, a failed assertion, a missed heartbeat).
Degraded — working, but not well. A monitor goes degraded when it responds slower than your response-time threshold, when ping loss or latency crosses a limit you set, when a TLS certificate is close to expiring, or when a heartbeat job that sent /start runs past its max run time: either it is still going when the limit passes, or it finishes after it.
Unknown — CuliPulse temporarily can’t tell. If every checkpoint watching a monitor is unreachable (for example your only agent is offline) for three checks in a row, the monitor is marked unknown rather than down — because the target might be fine and the problem is on the watching side. The monitor’s “last checked” time freezes, and the readings on the page are the last ones we got: the monitor page says they may be out of date and names the agent that stopped sending results, with a link to it. The “can’t check” alert names the agent that stopped checking in and when it was last heard from, so you can tell “my site is fine” from “CuliPulse can’t see it”. If the monitor had an open incident, it’s closed at that point (see Incidents).

These are the four health states. A monitor can also be paused (you stopped it) or pending (newly created, before its first result; for a heartbeat that means “not protecting you yet”: it isn’t watched until its first check-in). Until that first result, a monitor shows no uptime figure and its daily strip stays empty. No results yet doesn’t count as 100% up.

If a pending monitor’s first check fails, it stays pending until enough failed checks in a row confirm the problem (the Alert me after setting, 2 unless you changed it; see Incidents). The top of its page says why it failed and what comes next. With the default of 2 it reads, for example, “Last check failed: Couldn’t connect — port closed or refused — confirming on the next check (~14:35)”. If you set a higher number it says how many more failed checks are needed before you get an alert, for example “2 more failed checks before we alert you”. If you fix the problem first, the next good check turns it green and no alert is sent. The same reason is listed per location on the Checkpoints tab.

A paused monitor, and a monitor left with no location (for example its only agent was removed), isn’t being checked, so the latest reading on its page can be days old. The page says so instead of judging how fast it was.

Each bar in the daily strip on a monitor’s detail page is one day. The strip covers the last 90 days (30 days on the Free plan). Green means no problems, amber means the monitor was degraded (slow, or close to a limit you set) at some point that day but never went down, red means it was down at some point that day, and empty means there’s no data for that day yet. Degraded time doesn’t lower the uptime percentage shown next to it — that figure only counts time spent down.

Above the strip, Uptime period picks what the uptime figure covers: 30 days, 90 days, 1 year or 2 years. How far back you can look depends on your plan: 30 days on Free, 1 year on Solo, 2 years on Pro. Longer periods show a lock and the plan that includes them.

Avoiding false alarms

Wait for repeated failures

A monitor is only marked down after a number of consecutive failed checks — you set this as “Alert me after” (1 to 5 failures). Likewise, a down monitor only flips back to up after a number of consecutive successful checks (“Mark healthy again after”, 1 to 5). A recovery from degraded back to up is immediate.

The alert waits for that number of failed checks, but the incident does not: it is dated from the first failed check, so its duration, your uptime figure and the “since” time in the alert count the whole outage. See Incidents.

Heartbeat monitors are the exception: they don’t wait for repeated failures. A heartbeat goes down at the first missed check-in (after its grace period) and goes back up at the next check-in, whatever “Alert me after” says. Use the heartbeat’s grace period to allow for a late check-in. See Heartbeat monitors.

Degraded is flap-protected the same way — it takes repeated breaches, not one slow response, to go degraded. Heartbeats are the exception here too: a heartbeat goes degraded at once, when a run passes its max run time.

More than one checkpoint

When you watch a target from several checkpoints, CuliPulse only declares it down once enough of them agree — this avoids alarms caused by a routing problem near a single location rather than a real outage. In the app this is the “Only alert if more than one location fails” option. With it off, any one location failing marks the monitor down. With it on, the protection holds while all your locations are reporting. Checkpoints that are themselves unreachable simply abstain — they never count toward a “down” — and the monitor then needs agreement only from the locations that are reporting. So if one of two locations is offline, the other alone can mark the monitor down, and the monitor page shows which location isn’t checking in. Vendor status, domain and DNS monitors are checked once by CuliPulse itself rather than from checkpoints, so this option doesn’t apply to them.

What’s in an alert

Every alert is written in plain language and includes:

the state (down, degraded, recovered, unknown) and a short symptom — the actual cause, like “Request timed out”, “HTTP 503 (service unavailable)” or “Domain not found (expired, mistyped, or no DNS record)”, not just “failed” (see what each cause means). For port (TCP) and UDP monitors it also separates “couldn’t connect” from “connected, but the reply didn’t match — expected 220”, so a wrong payload doesn’t look like an outage (see Why is my port monitor down?);
which checkpoints saw it down and which saw it up;
when a monitor checks from two or more locations and only some were reporting at that moment, one extra line says so, for example Only 1 of 3 locations is reporting (Frankfurt and Office NAS are silent) — this result may not reflect every location. It appears on down alerts in Telegram, Slack and email, and is left out when every location is reporting. It is not added to the webhook payload, which is unchanged;
how long it’s been going (and, on recovery, the total outage duration);
the response time, only when the target actually answered. A down alert for a timeout, a refused connection, a silent port or a reply that didn’t match the expected text has none, because the time spent waiting isn’t a response time. A page that answers with an error (such as HTTP 503) still shows how long it took;
a link straight to the monitor (or the specific incident) in the console.

The same information is delivered to every destination you’ve connected — see Notifications. For the exact machine-readable shape, see the webhook payload.

Latency numbers on the console

Average latency, p95, the latency column in the monitor list and the Overview average count successful checks only. A failed check (a timeout, a refused or silent port) has no response time to average, so it is left out and shows as a gap in the latency chart. An error reply such as HTTP 503 is also left out of these console figures, but its response time still appears in the alert. A failed check’s red bar still counts against uptime. A monitor whose latest check failed shows “—” for latency.

Incidents

When a monitor goes down or degraded, CuliPulse opens an incident and closes it on recovery. If the failure changes while the monitor is still down (for example from HTTP 503 to HTTP 502), the incident updates to show the latest failure within a few minutes, and the recovery message names the last failure seen before the monitor came back. Each monitor’s detail page lists its past incidents with their duration, newest first; Load older pages further back, as far as your plan’s history reaches. The Overview page shows all open incidents across everything you watch. Uptime in Reports is calculated from these incidents. For exactly when an incident starts and ends, how it counts toward uptime, and what each cause means, see Incidents.

An incident also closes, without a “recovered” alert, when nothing can check the monitor any more: you delete its only agent, or every checkpoint watching it stays unreachable long enough for the monitor to turn unknown. CuliPulse can’t tell whether the target is still failing, so the incident stops counting downtime at that moment rather than staying open and lowering your uptime for time nobody measured. When a checkpoint can check again:

if the target is still failing, a new incident opens and you get a fresh “down” alert;
if the target is fine, the monitor simply turns up, with no alert.

The same goes for vendor status, domain and DNS monitors, which CuliPulse checks itself: if it can’t read the status page or the lookup three times in a row, the open incident closes, and if it’s still failing once CuliPulse can read it again, a new incident opens with a fresh “down” alert.

Pausing a monitor closes its open incident the same way.

“HTTP 200 — expected 3xx”

A website monitor counts a reply as healthy only when its status code is one you expect (the Expected status, 2xx by default). When the reply is a different success or redirect code (below 400), the incident and the alert say what was expected, for example HTTP 200 — expected 3xx or, for a default monitor that got a redirect, HTTP 301 — expected 2xx. The monitor is down because the reply wasn’t what it was told to expect, not because the site is unreachable. To fix it, either change the site or edit the monitor’s Expected status.

An error reply such as HTTP 503 (service unavailable) is shown as it is, with no extra note, because it already explains itself. The note appears on an error reply only when you set an Expected status that includes an error code yourself, for example HTTP 500 (server error) — expected 404.