---
title: Quick start
description: Sign up, add your first monitor and receive your first confirmed alert in a few minutes — from the dashboard or from an AI agent.
canonical: https://watchfor.io/docs/quick-start
---

# Quick start

Sign up, add your first monitor and receive your first confirmed alert in a few minutes — from the dashboard or from an AI agent.

This walkthrough takes you from zero to a monitor that alerts you when
something breaks. There is nothing to install: checks run from WatchFor's own
locations. A free plan is enough for everything on this page.

## Create your account

### Sign up

Create an account with your email or Google and, when asked, give yourself a
display name. WatchFor creates a **workspace** (organization) for you
automatically — you can rename it later under **Settings → General**.

### Your default alert path is ready

Every new workspace starts wired up, so the first alert never falls into the
void:

- a **contact** for your email address,
- a default **contact group** (named *On-Call*) containing that contact,
- an **email channel** (*Default Email — your workspace*) attached to that
  group,
- a **weekly email report**, switched on.

You can rename, extend or replace any of these later under **Alerting →
Channels & contacts** (the **Contacts** tab holds the people, **Channels**
the destinations). See
[Notifications](/docs/notifications#the-default-channel).

## Add your first monitor

### Open Monitors and create one

Go to **Monitors** and click **Create Monitor**. Pick a **type** — start with
**HTTP** for a website or **API** for an endpoint whose response you want to
validate — then fill in:

| Field | What to enter |
| --- | --- |
| **Name** | A label you will recognize in alerts, e.g. `Marketing site` |
| **Target** | The URL, e.g. `https://example.com` |
| **Frequency** | How often to check. Available intervals depend on your [plan](/pricing) |
| **Locations** | The region (or individual locations) to check from; plans decide how many |
| **Tags** | Optional, e.g. `prod`, `team:web` — used for filtering, bulk actions and maintenance windows |

Save. Checks start immediately; within a minute or two the monitor shows its
first result and a live status.

### Alerting is already on

You did not configure any rule, yet the monitor can already alert:

- WatchFor added **system alert rules** for the type — an *Availability
  Check* (critical) for every type, plus type defaults such as *Unexpected
  Status Code* for HTTP or *SSL Expiry Warning* for API monitors.
- The monitor's **Notification targets** point at your default contact group,
  so alerts reach the default email channel.

Open the monitor's **Alerting** tab to see them. Switch on more presets —
*Response Time*, *SSL Certificate*, *Response Body Match* — and adjust
thresholds there. Details: [Alert rules](/docs/alerting).

### Add a channel your team actually watches (optional)

Email is fine to start. To get alerts in Slack, Discord, Telegram, Microsoft
Teams, PagerDuty, a webhook and more, go to **Alerting → Channels & contacts → Add
Channel**, attach the channel to your contact group, pick the severities it
should receive and click **Send test**. See
[Notifications](/docs/notifications#adding-a-channel).

## What happens when something breaks

1. A check fails. The monitor shows **Degraded** and WatchFor starts
   **re-checking on an accelerated schedule** from the monitor's locations.
2. The failure keeps reproducing until the rule's threshold is met (three
   consecutive failed checks by default). Now it is **confirmed**: an
   **incident** opens and the monitor shows **Down**. A failure that stops
   reproducing never becomes an incident and never pages anyone.
3. **Notifications** go out to the channels attached to the monitor's contact
   group; if an escalation policy is attached, on-call is paged.
4. The incident page shows the [root cause](/docs/alerting/root-cause): what
   was expected, what was detected, from which locations, and why it usually
   happens.
5. When the target recovers, the incident **resolves** and a recovery
   notification is sent.

The full sequence is in [How a failure becomes an incident](/docs/monitors/scheduling#how-a-failure-becomes-an-incident);
the status model is in [Core concepts](/docs/core-concepts#monitor-status).

## Next steps

	- [Monitor types](/docs/monitors): 25 check types — websites, APIs, MCP servers, DNS, certificates, email, network path, cron jobs, Core Web Vitals and more.
	- [Status page](/docs/status-pages): Publish a public status page for your users in about a minute.
	- [On-call & escalations](/docs/alerting/on-call): Rotations, overrides and escalation policies that page a person until someone acknowledges.
	- [Maintenance windows](/docs/monitors/maintenance): Silence planned work and keep it out of your uptime numbers.

## Doing this from an AI agent?

Everything above is available programmatically. Create an API key under
**Settings → API keys** (owners and admins; choose *read + write* for
automation), then:

```bash
curl -X POST https://watchfor.io/api/v1/monitors \
  -H "Authorization: Bearer wf_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Marketing site", "type": "http",
        "target": "https://example.com", "interval": 60,
        "locations": ["<location id from GET /v1/locations>"] }'
```

The same call seeds the same system alert rules and default notification
route as the dashboard. For Claude, Cursor and other MCP clients, connect the
[MCP server](/docs/api/mcp) instead and ask it to create the monitor; AI agents
that delegate tasks can use the [A2A endpoint](/docs/api/a2a). Start at the
[API overview](/docs/api) — it also lists the `watchfor` SDKs and CLI for
TypeScript, Python and Ruby.

---

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