---
title: Core concepts
description: Monitors, checks, alert rules, incidents, channels and status pages — and the exact meaning of Up, Degraded, Down, Paused and Unknown.
canonical: https://watchfor.io/docs/core-concepts
---

# Core concepts

Monitors, checks, alert rules, incidents, channels and status pages — and the exact meaning of Up, Degraded, Down, Paused and Unknown.

A handful of words show up everywhere in WatchFor — in the dashboard, in
notifications, in the REST API and in the MCP server. This page defines them
once. If you only read one section, read [Monitor status](#monitor-status): it
is the canonical explanation of what **Down** and **Degraded** mean.

## Monitor

A **monitor** is one thing you want to keep an eye on: a website, an API
endpoint, an MCP server, a TCP port, a DNS name, a TLS certificate, a domain, a
mail server, a cron job. Each monitor has:

- a **type** (which decides *how* it is checked — 30 [types](/docs/monitors)),
- a **target** (the URL, host, `host:port` or domain being checked),
- a **check interval** and a set of **locations** (see
  [Locations & scheduling](/docs/monitors/scheduling)),
- optional **tags**, a description and type-specific settings,
- its own **alert rules** and **notification targets** (the monitor's
  **Alerting** tab).

## Check

A **check** is one execution of a monitor: one request, from one location, at
one moment. A monitor with a 60-second interval produces one check per minute,
rotating through its locations. Checks are what you see in a monitor's history,
uptime and response-time charts. That history starts at the monitor's creation
— or at its last **Reset history**, which wipes everything a monitor has
recorded while keeping the monitor itself (see
[Actions on a monitor](/docs/monitors#actions-on-a-monitor)).

A check is recorded as **successful** when the probe reached the target and
got a response back. Whether that response is *acceptable* is a separate
question, decided by the monitor's [alert rules](/docs/alerting): an HTTP 500,
a wrong status code, a failed API assertion or an expired certificate is a
check that succeeded in reaching your service and then failed a rule — it
shows up as **Degraded** and, once confirmed, as an incident. That is why
**check success** (and the Probes tab's *Reachable* figure) is a
reachability and flakiness signal, not a health signal: read
[uptime](/docs/monitors#how-uptime-is-calculated) for health, and check
success for "could we get an answer at all".

## Location

A **location** is a place WatchFor runs checks from. There are 20 locations in
7 world regions (Europe, Asia, Middle East, North America, South America,
Oceania, Africa — see [probe locations](/docs/reference/probe-locations)). Your
plan decides how many regions and hand-picked locations a monitor can use.
Checking from several places is what separates "the internet path from one
city is broken" from "the service is down".

## Alert rule

An **alert rule** turns a check result into a yes/no decision: *is this a
problem?* A rule compares one **metric** of the result (HTTP status, response
time, days until certificate expiry, packet loss…) against a **threshold** and
carries a **severity**:

| Severity | Meaning | Effect |
| --- | --- | --- |
| **Critical** | The thing is broken or about to be. | Monitor shows **Down** once confirmed, and stays Down while the incident is acknowledged; pages on-call. |
| **Warning** | Worth knowing, not worth waking anyone. | Monitor shows **Degraded**; goes to channels, never pages on-call. |

There are exactly two severities, and Critical outranks Warning: when a
preset's warning and critical thresholds on the same metric are both crossed,
only the critical incident opens, and while a critical incident is open on a
monitor its warning alerts are held back until it resolves — see
[Critical outranks warning](/docs/alerting/incidents#critical-outranks-warning).
Each notification channel has a severity filter, so a channel can receive
Critical only, or both.

Every new monitor gets **system rules** automatically (an *Availability Check*
plus type-specific defaults), and each type ships **presets** you can switch
on and tune. See [Alert rules](/docs/alerting).

## Confirmation

A single failed check never opens an incident. When a check fails, WatchFor
re-checks on an accelerated schedule, rotating through the monitor's
locations, until the rule's failure threshold is met (3 consecutive failed
checks by default) — or until the failure stops reproducing, in which case
nothing happens. This is what "confirmed" means throughout the product. The
exact cadence, and the monitor types that are exempt from it, are in
[How a failure becomes an incident](/docs/monitors/scheduling#how-a-failure-becomes-an-incident).

## Monitor status

Every monitor shows one of five statuses. The rule that matters most:
**Down is reserved for an open, confirmed Critical incident.** A failing check
on its own is Degraded, and so is a Warning incident.

The precedence, top to bottom:

1. **Paused** — you stopped the checks; nothing else applies.
2. **Down** — a Critical incident is open (firing *or* acknowledged).
3. **Degraded** — a Warning incident is open, or a check is failing (any
   alert rule: availability, status code, response time, content,
   assertions…) without a confirmed incident yet.
4. **Up** — the latest check passed.
5. **Unknown** — no result yet.

| Status | What it means | What produced it |
| --- | --- | --- |
| 🟢 **Up** | The latest checks pass and no incident is open. | A successful latest check. |
| 🟠 **Degraded** | Something is off, but it is **not a confirmed outage**. | A failing check (any alert rule — an HTTP 500 or a slow response counts within one check) whose confirmation is still in progress, **or** an open **Warning** incident (slow response, certificate expiring soon, packet loss…). |
| 🔴 **Down** | A **confirmed Critical incident** is open — firing or acknowledged. | A Critical rule met its failure threshold; notifications have gone out. Acknowledging the incident does not change the status; only resolving it does. |
| ⏸️ **Paused** | You stopped the checks. | You paused the monitor. Nothing is tested and no incidents open. |
| ⚪ **Unknown** | No result yet. | A brand-new or just-resumed monitor, or a domain-expiry monitor whose registry does not publish a date. A just-resumed monitor keeps showing its history with a **Resuming** marker until the first new check. An open incident overrides Unknown. |

Small markers next to the status add detail without changing it:

- **Confirming n/m** — on Degraded: the failing rule has failed *n* of the
  *m* checks in a row it needs before an incident opens.
- **Recovering n/m** — on Down (or a Degraded Warning incident): the checks
  pass again and *n* of the *m* passing checks needed to resolve the
  incident are in. The status stays Down until the incident resolves.
- While confirming or recovering, the monitor is checked **faster** than its
  interval so the answer comes sooner. The header then reads, for example,
  *Every 5m · 30s while confirming*, and **Next check in** counts down from
  the faster interval.
- **Down since / Degraded since** — the time of the first failed check of
  the current streak, the same moment the incident timeline starts from.
- **Muted** — outbound notifications for the monitor are silenced for a
  chosen time (1 hour to 7 days); checks and incidents continue. See
  [Muting a monitor](/docs/notifications#muting-a-monitor).
- **Maintenance** — an active [maintenance window](/docs/monitors/maintenance)
  covers the monitor; alerts are silenced and, if you chose so, the period is
  excluded from uptime.

Two types deliberately do not turn a failed check into Degraded: **domain
expiry** (a registry lookup that fails is a lookup problem, not an expired
domain) and **heartbeat** (the missed-ping rule is the whole signal). For
these, only their own rules drive the status.

The same status model is used by the dashboard, the [status pages](/docs/status-pages),
the [REST API](/docs/api/monitors) (`status` field, including `degraded`),
[`GET /v1/summary`](/docs/api/summary) and the MCP server, so a number you
see in one place matches the others.

## Incident

An **incident** is one confirmed problem with a lifecycle:

```
firing  →  acknowledged  →  resolved
```

It opens when a rule's condition is confirmed, records who was notified and
what the team did, carries a [root-cause breakdown](/docs/alerting/root-cause),
a timeline and [internal notes](/docs/alerting/internal-notes), and resolves
automatically when the condition recovers (or by hand — see
[Resolving incidents](/docs/alerting/resolving)). While it is open, the
monitor keeps checking faster than its normal interval so recovery is noticed
quickly. Details: [How incidents work](/docs/alerting/incidents).

Only confirmed **Critical** incidents count as downtime. A resolved incident
that turns out to have been a **false positive** can be marked as one: it
stays on record but leaves uptime, reports and the public status page (see
[False positives](/docs/alerting/resolving#false-positives)).

## Notification channel, contact group, route

A **channel** is a destination: email, Slack, Discord, Telegram, Microsoft
Teams, PagerDuty, Opsgenie, webhooks and [more](/docs/notifications). A
**contact group** is a named set of people (contacts) that a monitor's alerts
are addressed to; channels are attached to groups. The chain
*monitor → contact group → channel* is a **route**. Every new organization
starts with a default group and a default email channel, so a first alert
always has somewhere to go. See [Contacts & groups](/docs/notifications/contact-groups).

## On-call & escalation

A **schedule** decides who is on call at any moment (rotations, layers,
overrides). An **escalation policy** is the chain that pages them — person by
person, step by step — until someone **acknowledges** a Critical incident.
People are paged through their own methods (email, Telegram, ntfy, Pushover,
Gotify, Pushbullet), not through shared channels. See
[On-call & escalations](/docs/alerting/on-call).

## Maintenance window, mute, pause

Three ways to make WatchFor quiet, for three different situations:

| | Checks keep running | Incidents still recorded | Notifications | Uptime |
| --- | --- | --- | --- | --- |
| **Maintenance window** | yes | yes, badged *Maintenance* | silenced | optionally excluded |
| **Mute** | yes | yes, notifications marked *Silenced* | silenced for 1 h – 7 d | unchanged |
| **Pause** | no | no | none | not measured |

## Status page

A **status page** is the public, customer-facing view: which services are up,
any ongoing incidents, scheduled maintenance and uptime history — on your own
subdomain, public, private or password-protected. See
[Status pages](/docs/status-pages).

## Organization

Everything lives inside an **organization**: monitors, rules,
channels, status pages, API keys and billing. People join with a **role** —
owner, admin or member — that controls what they can change; team members
are included on every plan. See [Your organization](/docs/organization).

## Humans and AI agents

Everything above is also available programmatically with the same data and
the same permissions: the [REST API](/docs/api), the [MCP server](/docs/api/mcp)
for Claude, Cursor and other MCP clients, and an [A2A endpoint](/docs/api/a2a)
for agents that delegate tasks. An AI agent can create a monitor, read an
incident's root cause or acknowledge it exactly as a person would.

## How they connect

> **Info**
>
> A **monitor** runs **checks** from several **locations** → an **alert rule**
> judges each result → a failure is **confirmed** → an **incident** opens →
> **channels** notify your team and **on-call** is paged → your **status
> page** keeps customers informed → recovery **resolves** the incident → a
> **post-mortem** and **reports** keep the record.

Ready to go deeper? Start with the [quick start](/docs/quick-start) or
[Monitors](/docs/monitors).

---

Canonical page: https://watchfor.io/docs/core-concepts · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt