---
title: Monitors overview
description: What a monitor is, how checks run, the statuses you'll see, and everything you can do with a monitor from the dashboard or the API.
canonical: https://watchfor.io/docs/monitors
---

# Monitors overview

What a monitor is, how checks run, the statuses you'll see, and everything you can do with a monitor from the dashboard or the API.

A **monitor** is one thing you want to keep healthy — a URL, a hostname, a
port, a domain, a cron job, an MCP server. You give it a **type** and a
**target**, choose how often to check and from where, and WatchFor runs the
**checks**, confirms failures, opens **incidents** and notifies you.

WatchFor is modern uptime & infrastructure monitoring, for humans and AI
agents: everything on this page is available in the dashboard and through the
[REST API](/docs/api/monitors), the [MCP server](/docs/api/mcp) and
[A2A](/docs/api/a2a).

## Anatomy of a monitor

| Setting | What it does |
| --- | --- |
| **Type** | How the target is checked — one of [25 types](#monitor-types). Fixed after creation (create a new monitor to change it). |
| **Target** | What is checked — a URL, hostname, IP, `host:port` or domain, depending on the type. Each type page lists its target format. |
| **Name** and **description** | How the monitor appears in lists, incidents and notifications. |
| **Interval** | How often a check runs. The minimum depends on your plan and the monitor type — see [Locations & scheduling](/docs/monitors/scheduling). |
| **Locations** and **strategy** | Where checks run from, and whether one location checks per run (rotating) or all of them at once. |
| **Tags** | Labels for grouping, bulk actions, status-page components and maintenance windows — see [Tags](/docs/monitors/tags). |
| **Alert rules** | What counts as a problem. Every type ships with sensible defaults; tune or add more on the monitor's **Alerting** tab — see [Alerting](/docs/alerting). |
| **Type-specific settings** | Request method and auth for HTTP, record type for DNS, ping count for ICMP, and so on — under **Settings → Advanced Options** on the monitor. |

## How checks run

Each check is one probe of the target from one location. WatchFor runs checks
on your interval from a global network of [probe locations](/docs/reference/probe-locations)
across seven world regions.

A single failed check does **not** open an incident. WatchFor re-checks on an
accelerated schedule from your monitor's locations, and only when the alert
rule's failure threshold is met does an incident open and notify you. This is
why the dashboard distinguishes **Degraded** (a check failed, unconfirmed) from
**Down** (a confirmed incident). The full sequence, and the monitor types that
are exempt from it, is described in [Locations & scheduling](/docs/monitors/scheduling#how-a-failure-becomes-an-incident).

Checks use IPv4 by default. Every type except heartbeat, Core Web Vitals and
email policy lets you force IPv4 or IPv6 — or keep *Auto*, which prefers IPv4
and falls back to IPv6 — under **Settings → Advanced Options**; see
[Choosing IP version](/docs/reference/probe-locations#choosing-ip-version).

## Monitor statuses

	- [🟢 Up](#): The latest checks are passing.
	- [🟠 Degraded](#): A check failed but no incident has been confirmed (yet), or a **Warning** incident is open.
	- [🔴 Down](#): A confirmed **Critical** incident is open (firing or acknowledged) for this monitor.
	- [⏸️ Paused](#): You stopped the checks; nothing is being tested.
	- [⚪ Unknown](#): No results yet — a brand-new monitor, or a domain monitor whose registry doesn't publish an expiry date.

> **Info**
>
> **Down** means exactly one thing: a Critical incident is open for the
> monitor, whether it is still firing or already acknowledged. A monitor with
> a confirmed incident shows Down everywhere — the list, the API, status
> pages and reports — even between checks. Warning incidents show as
> Degraded, never Down. Paused always wins. The full precedence is in
> [Core concepts](/docs/core-concepts#monitor-status).

## Creating a monitor

Go to **Monitors → Create Monitor**, pick a type, enter the target and choose
the interval, locations and tags. You can also tick **Create in paused state**
to set a monitor up now and start it later.

The dialog does the fiddly parts for you: required fields (**Name**,
**Target**, **Locations**) are marked with an asterisk and an invalid submit
scrolls to the first problem; the first available region is **preselected**
so a monitor is never created with nowhere to run; switching the type resets
the interval to the default and re-applies the **new** type's plan minimum,
so you never carry the previous type's floor into the new one; and a
heartbeat's **cron expression** is validated as you type, with the reason
shown under the field.

Every new monitor gets a set of **default alert rules** for its type (for
example *Availability Check* on almost every type, *SSL Expiry Warning* on SSL
monitors, *Missed Schedule* on heartbeats). Switch them off or tune them from
the monitor's **Alerting** tab — you never start from a blank page.

Other ways to create monitors:

- **Clone** — from a monitor's **⋯** menu. Copies the settings and every alert
  rule of the source monitor, so a fleet of similar checks takes seconds.
- **Import** — **Monitors → Import**. Upload a CSV, or migrate directly from
  UptimeRobot, StatusCake, Pingdom, Checkly, Site24x7 or Instatus. The CSV
  format is `name,type,target,interval,locations`; `locations` accepts a
  region, country, city or country code, and several can be combined with `;`
  (for example `europe;asia`).
- **API, MCP and A2A** — create one monitor or thousands in a single bulk
  call. See [Monitors API](/docs/api/monitors#create-a-monitor) and
  [Bulk operations](/docs/api/monitors#bulk-operations).

Plan limits apply to the number of monitors (overall and, on some plans, per
type). See [/pricing](/pricing).

## The monitors list

**Monitors** in the sidebar lists everything in the workspace, as cards or as
rows (the toggle top-right). Search, the status and type filters, the view
and the page live in the **URL**, so a filtered list is a link you can
bookmark or paste to a colleague and reload without losing your place. Both
views share one page-size ladder — 12, 24, 50 or 100 per page.

The **Latency (24h)** and **Uptime (24h)** columns say which window they
cover, and a paused monitor's uptime is labelled *· paused*: no checks ran,
so the paused time counts as up and the label stops you reading a rising
number as a live signal. Select several monitors for the bulk actions
(pause, resume, tags, delete), and use the header's **Create monitor** and
**Import** buttons — visible on phones too, and disabled with the reason for
members, since creating monitors is an owner/admin action.

## The monitor page

Open any monitor to see:

| Tab | What's there |
| --- | --- |
| **Overview** | Uptime, response time and the type-specific cards (certificate details, DNS records, Core Web Vitals scores, tool inventory, …). |
| **Alerting** | The alert rules for this monitor — presets with thresholds and severities. |
| **Incidents** | Every incident this monitor has had, with root cause and timeline. |
| **Probes** (**Pings** for heartbeats) | The individual checks, per location, with the captured response. Filter by location (**All locations**) when the monitor runs from more than one, and page through the history with the *Showing 1–15 of 34 · Page 1 of 3* pager. |
| **Setup** (heartbeats only) | Copy-paste snippets for your cron line or script. |
| **Uptime SLA** | Uptime over a period with maintenance excluded, printable as a report — see [The Uptime SLA tab](#the-uptime-sla-tab). |
| **Settings** | Name, target, interval, locations, tags and the type-specific options. |

The header above the tabs carries the live facts: interval, scheduling
strategy, when the last check ran and **Next check in ≈ 42s** — an estimate
from the interval and the last result, so you know whether to wait or to
run one now. It is not shown for paused monitors or heartbeats, which wait
for your job's next ping. Every time on the page (and in incidents, the
Probes tab and the delivery log) follows your **profile time zone and
12/24-hour setting** — avatar → Settings → Profile.

### How uptime is calculated

Every uptime figure — the monitor cards, the list sort, the **Uptime** card
and SLA tab on the monitor page, [reports](/docs/reports) and the
[API](/docs/api/checks-uptime) — uses one formula:

```
uptime = (observed − time in critical incidents − scheduled maintenance) / observed
```

Only **critical** incidents count as downtime; a warning incident shows the
monitor as Degraded but does not reduce uptime, and an incident marked as a
[false positive](/docs/alerting/resolving#false-positives) is left out
entirely. Scheduled maintenance is neutral (neither up nor down). `observed`
is the last 24 hours, **clamped to the monitor's creation time** — or to its
last [history reset](#actions-on-a-monitor), whichever is later: a monitor
created 10 minutes ago is judged on those 10 minutes, and its card says
*Uptime — since created (10m)* until it is a day old; after a reset it says
*since reset (10m)* in the same way. The Uptime SLA tab uses the same rules
over longer periods.

**Uptime is not the same as check success.** Check success — the figure next
to uptime, in [reports](/docs/reports) and on the
[API](/docs/api/checks-uptime) — is the share of checks where the probe
*reached the target and got a response*. A response that then fails a rule
(the wrong status code, a failed API assertion, an expired certificate)
counts as reached, so a monitor can be **Down at 100% check success**. Read
check success for flakiness — timeouts, refused connections, DNS failures,
one city misbehaving — and uptime for health.

### The Uptime SLA tab

The **Uptime SLA** tab breaks the same formula down by day, week or month,
and prints as a report. So that its numbers never surprise you:

- Only **confirmed critical incidents** count as downtime; incidents marked
  as [false positives](/docs/alerting/resolving#false-positives) are left out
  of every row and of the printed report.
- An incident that has been **acknowledged but not resolved is still
  downtime** — acknowledging says "someone is on it", not "it's fixed".
- Time inside [maintenance windows](/docs/monitors/maintenance) is
  excluded; the tab says how much (*excludes 2h of scheduled maintenance*).
- Rows are bucketed in **your profile time zone** (avatar → Settings →
  Profile), so a day means your day; weekly rows cover seven full calendar
  days.
- **Paused time counts as up** — no checks ran, so nothing could fail; the
  Uptime card says *· paused* while a monitor is paused.
- The printed report starts at the monitor's creation or its last
  [history reset](#actions-on-a-monitor), whichever is later, and says so
  (*Monitoring since …*).

## Actions on a monitor

From the **⋯** menu on the monitor page (most are also available on the list):

- **Pause / Resume** — pausing stops the checks entirely; the monitor shows
  **Paused**, open incidents are closed, no new ones open and nothing is
  counted. If the monitor **has an open incident**, Pause asks you to confirm
  first and says what will happen: the incident (acknowledged ones included)
  is resolved and your channels get a *resolved — monitor paused* notice.
  To keep the incident open and only silence the notifications, use **Mute**
  instead. With nothing open, Pause is a single click; a bulk pause always
  confirms and names how many of the selected monitors have an open incident.
  Pausing also **clears the monitor's failure counters**, so after a resume a
  new incident needs the full confirmation threshold again, counted from the
  first failure after the resume. A resumed monitor shows **Unknown** — never
  a stale Up — until its next check lands; that rule holds everywhere, on the
  monitors list, the monitor page and the [API](/docs/api/monitors#resume-a-monitor).
  While paused, the paused time counts as up in uptime figures (there are no
  checks to say otherwise); the uptime label says *· paused* so you can tell.
- **Run check now** — dispatch one check immediately, outside the schedule.
  The check is queued rather than run in front of you: the confirmation says
  *the result is on its way* and the page picks it up on its own, usually
  within a minute. The result flows through the normal pipeline (it can
  confirm or resolve an incident). Each plan includes a per-monitor hourly
  budget; once it is spent the menu item is disabled and says when the
  allowance reopens (*limit reached, ~60 min*). Owners and admins only; not
  available for paused or heartbeat monitors.
- **Mute alerts** — for 1 hour, 8 hours, 24 hours or 7 days. Checks and
  incidents continue; only the notifications are held. For planned work,
  prefer a [maintenance window](/docs/monitors/maintenance), which also keeps
  the time out of your uptime figures.
- **Test notifications** — send a test through the monitor's notification
  route to make sure the right people receive it.
- **Clone** — see above.
- **Reset history** — deletes everything the monitor has ever recorded and
  starts its statistics from zero: check and latency history, incidents with
  their timelines and notification history, internal notes, post-mortems and
  the incidents that were auto-published to your status pages. The monitor
  itself stays as it is — same id, settings, alert rules, tags, locations
  and status-page components — and checks carry on; it shows **Unknown**
  until the next result lands and its uptime reads *since reset* until the
  window fills again. Owners and admins only; the dialog asks you to type the
  monitor's name because this cannot be undone. Reach for it after a long
  misconfiguration or a staging phase you don't want in the numbers — for a
  single wrong incident, mark that incident as a
  [false positive](/docs/alerting/resolving#false-positives) instead.
- **Delete** — removes the monitor and everything it recorded: checks and
  latency history, every incident with its timeline and notification history,
  internal notes and post-mortems, and its entries on your status pages
  (published incident history included). Its alert rules and its membership
  of maintenance windows go too. The confirmation spells this out, because it
  cannot be undone — to stop the checks but keep the history, **Pause**.

**Bulk actions** — select several monitors in the list to **Pause**,
**Resume**, **Add tags**, **Remove tags** or **Delete** them together.

Also via API: [pause](/docs/api/monitors#pause-a-monitor),
[resume](/docs/api/monitors#resume-a-monitor),
[run a check now](/docs/api/checks-uptime#run-a-check-now),
[reset history](/docs/api/monitors#reset-history),
[delete](/docs/api/monitors#delete-a-monitor) and
[bulk operations](/docs/api/monitors#bulk-operations).

## Monitor types

WatchFor supports **25 check types**. Browse them by category:

	- [Web & uptime](/docs/monitors/web): HTTP / HTTPS websites and endpoints — status, latency, keywords, SSL.
	- [API](/docs/monitors/api): JSON, header and body assertions plus value extraction — is the response *correct*, not just answered.
	- [Heartbeat & cron jobs](/docs/monitors/heartbeat): Alerts when a scheduled job or worker *doesn't* check in.
	- [MCP servers](/docs/monitors/mcp): Model Context Protocol handshake, tool inventory and drift detection.
	- [Network](/docs/monitors/network): Ping (ICMP), TCP, UDP, DNS and network path (MTR).
	- [Certificates & domains](/docs/monitors/certificates): SSL/TLS certificates, daily TLS grade and domain expiry.
	- [Email](/docs/monitors/email): SMTP servers and email policy (SPF / DMARC / DKIM).
	- [Security](/docs/monitors/security): Blacklist (RBL) listings and data-breach exposure.
	- [Performance & content](/docs/monitors/performance): Core Web Vitals, CDN, Brotli, CMS, favicon, sitemap, WebSocket, NTP, FTP and SFTP.

The machine-readable version of every type — target format, config fields and
alert metrics — is served by the API at
[`GET /v1/meta/monitor-types`](/docs/api/monitor-types).

## Organizing monitors

- **[Locations & scheduling](/docs/monitors/scheduling)** — intervals,
  regions and cities, round-robin vs. parallel, and how a failure becomes an
  incident.
- **[Tags](/docs/monitors/tags)** — group and filter monitors, build
  status-page components and target maintenance windows.
- **[Maintenance windows](/docs/monitors/maintenance)** — suppress alerts and
  exclude planned work from uptime without pausing the checks.

---

Canonical page: https://watchfor.io/docs/monitors · All docs: https://watchfor.io/docs · Site guide: https://watchfor.io/llms.txt