# Check intervals

The **interval** is how often a monitor runs its check. A shorter interval notices an outage sooner and gives
finer response-time data; a longer one is enough for things that change slowly. For calendar-style schedules
("every Monday at 09:00") use a [cron schedule](/monitors/advanced/cron-scheduling/) instead.

## Settings reference

| Setting (app label) | API field (v2) | Type / allowed values | Default | Plan limits | What it does for you |
|---|---|---|---|---|---|
| **Interval** (under **Interval schedule**) | `interval` | Integer **seconds**; must be one of the account's allowed values (`GET /account` -> `limits.intervals`) and at or above the type's and your plan's minimum | App: per type (table below). API: `180` (3 minutes) | Your plan sets the fastest interval | How often the check runs. |
| **Check interval** (Profile -> Defaults) | - (app only) | 1, 3, 5, 10, 15, 30 min; 1, 6, 12, 24 h; or **Built-in default** | Built-in default | Types with a larger minimum keep their own | The interval the **Add Monitor** form starts with. |

## The values you can pick

The app offers a fixed list per type, so every monitor lands on a value the scheduler supports:

| Monitor types | Intervals offered in the app | App default |
|---|---|---|
| Website/HTTPS, API, Ping, Port, Counter, SNMP | 1, 2, 3, 5, 10, 15, 30, 45 min; 1, 2, 4, 6, 12, 24 h | 3 min (SNMP 5 min) |
| Page speed, Transaction, Web content check, Database | 10, 15, 30, 45 min; 1, 2, 4, 6, 12, 24 h | 15 min (Page speed), 10 min (others) |
| Russian BL check | 30, 45 min; 1, 2, 4, 6, 12, 24 h | 1 h |
| SSL/TLS certificate expiry, Domain expiry, DNSBL | Fixed: every 6 hours | - |
| Web Risk | Fixed: every 12 hours | - |
| Site crawl | Cron only (weekly by default) | Mondays 03:00 UTC |

On the API the same values are sent in seconds: `60`, `120`, `180`, `300`, `600`, `900`, `1800`, `2700`,
`3600`, `7200`, `14400`, `21600`, `43200`, `86400`. The authoritative list for your account is
`limits.intervals` in `GET /account`; a value outside it is refused with `422 invalid_interval`, and the error's
`allowed` array lists the valid ones.

## Minimums: your plan and the monitor type

Two floors apply on top of the allowed list, and the stricter one wins:

- **Your plan's floor.** The permanent free plan checks every 30 minutes; the 30-day trial and the faster paid
  plans allow checks every minute (the exact floor depends on the plan). A plan can also set its own floor for specific types (for example Page speed). An
  interval below your plan's floor is refused with `403 package_limit` ("Your package's minimum check interval
  is ...").
- **The type's own floor.** Some checks are expensive or change slowly, so HostTracker sets a minimum regardless
  of plan:

| Type | Minimum interval |
|---|---|
| Page speed (`waterfall`), Database (`database`) | 10 minutes |
| Russian BL check (`http` with preset `bl:ru`) | 30 minutes |
| DNSBL, Domain expiry, SSL/TLS certificate expiry | 6 hours (fixed) |
| Web Risk | 12 hours (fixed) |
| Site crawl | 1 day (cron only) |
| Every other type | No minimum above 1 minute |

An interval below the type's floor is refused with `422 interval_below_type_floor` (the error carries
`minInterval`). If no allowed interval satisfies both floors - a type whose minimum is above everything your plan
offers - the answer is `403 package_interval_conflict`.

To read your effective floor per type, call `GET /monitor/type` with your token: each row's
`accountLimits.minInterval` (seconds) is the larger of the type's floor and your plan's, and `fixedInterval` is
present for the fixed-cadence types. MCP: **`list_monitor_types`**.

## Fixed-cadence types

**DNSBL**, **Domain expiry** and **SSL/TLS certificate expiry** monitors always run every **6 hours**, and **Web
Risk** monitors every **12 hours**. The app shows no interval control for them. On the API you can omit
`interval` - the monitor is created at its fixed cadence; a value you do send is still checked against the
allowed list and the type's floor, then the fixed cadence is stored anyway. A cron schedule is not supported for
these types (it is cleared with a warning).

The same four checks **attached** to a website monitor (see
[Attached sub-checks](/monitors/types/attached-sub-checks/)) run every **12 hours**, whatever the parent monitor's
interval.

## Set it up in the app

1. On **Sites**, open the monitor (or click **Add Monitor** for a new one).
2. Expand **Main Settings**.
3. Make sure **Interval schedule** is selected (not **Cron schedule**).
4. Pick the value in the **Interval** dropdown, or drag the slider.
5. **Save**.

To change the interval of many monitors at once, select them on **Sites** and use **Edit** -> **Monitoring
interval** (see [Bulk operations](/monitors/bulk-operations/)).

## Do it with the API or MCP

```bash
# Every 5 minutes (scope monitor:write)
curl -X PATCH "https://api2.host-tracker.com/monitor/$MONITOR_ID" \
  -H "Authorization: Bearer $HT_TOKEN" -H "Content-Type: application/json" \
  -d '{ "interval": 300 }'
```

- Create: include `"interval": 300` in `POST /monitor`. Omit it to get 3 minutes (or the fixed cadence).
- Switch a cron-scheduled monitor back to an interval: `{ "cronSchedule": null, "interval": 300 }`.
- MCP: **`update_monitor`** (`id`, `interval`) and **`create_monitor`** (`interval`). Pass **seconds** (`300` =
  5 minutes): the value is forwarded unchanged to the API's `interval` field.
- Many monitors: `POST /monitor/bulk-update` with `{ "ids": [...], "patch": { "interval": 300 } }`, MCP
  **`bulk_update_monitors`**.

## What happens next

The scheduler picks up the new cadence within about a minute of saving; from then on checks are spaced by the
new interval. Results already recorded are not changed.

## Limits and gotchas

- If you create a monitor without `interval` and 3 minutes is not allowed for that type on your plan, the API
  answers `422 validation_failed` with `reason: "required"` at `/interval` and lists the allowed values - send an
  explicit interval.
- A bulk interval change over mixed types fails, item by item, for monitors whose type floor is above the chosen
  value (`interval_below_type_floor`); the others are updated.
- If your plan changes to one with a slower floor, monitors that run faster are slowed to the new floor
  automatically.
- A monitor that has a cron schedule stores `interval: 0`; the two schedules are alternatives.

## Related

- [Cron scheduling](/monitors/advanced/cron-scheduling/)
- [Anatomy of a check](/monitors/anatomy-of-a-check/)
- [Plan limits](/reference/plan-limits/)
- [Choosing a plan](/getting-started/choosing-a-plan/)