# Input Sync Frequency

Every input connector pulls (or receives) data on its own cadence. This page
explains how often Monad syncs an input by default, what determines a specific
connector's cadence, and how to override it — useful for estimating API-call
volume and cost against a source provider's quota.

## How it works

Most input connectors run on a continuous polling cycle. By default, a new sync
begins roughly **every 10 seconds**, with each cycle starting 10 seconds *after*
the previous one finishes (not on a fixed 10-second clock). Each sync is
**incremental** — only records newer than the last checkpoint are fetched — so a
short interval does not re-pull data you already have.

The 10-second default is also a **floor**: a connector cannot poll faster than
once every 10 seconds.

Not every connector polls, though. The effective cadence depends on which of the
mechanisms below the connector uses.

## Sync mechanisms

| Mechanism | Default cadence | How it behaves |
| --------- | --------------- | -------------- |
| **Continuous polling** | ~10 seconds | The default for most REST-based connectors. Polls on the continuous cycle described above. |
| **Interval polling** | Connector-specific | Some connectors set their own interval — typically because the source produces data less frequently or enforces a tighter quota. Values range from 10 seconds up to 1 hour. A few (cloud object storage — Amazon S3, Google Cloud Storage, Azure Blob Storage) **adapt** their interval, syncing more often when a backlog builds up and backing off when caught up. |
| **Scheduled (cron)** | Hourly | Bulk/snapshot connectors (for example, asset, user, or configuration inventories) run on a cron schedule rather than continuous polling. The default is once per hour (`0 * * * *`); you can set any cron expression when configuring the input. |
| **Push / receiver** | Real-time | Connectors that *receive* data — webhooks, OTEL, syslog, HEC — are event-driven. Monad ingests records as the source sends them; there is no polling interval. |
| **Queue / subscription** | Source-driven | Connectors that consume from a message queue or subscription (Amazon SQS, Google Pub/Sub, Kafka, Azure Event Hubs, Azure Queue Storage) ingest at whatever rate the source delivers messages. |

Each connector's own page states which mechanism it uses and its specific cadence.

## Overriding the cadence with a cron schedule

You can override an input's default cadence by setting a **cron schedule** on the
pipeline. A valid cron expression takes precedence over both the 10-second
default and any connector-specific interval, and the input then syncs only on
that schedule.

The order of precedence is:

1. **Pipeline cron schedule** — if set, always wins.
2. **Connector-specific interval** — for connectors that define one (never
   faster than the 10-second floor).
3. **The 10-second default** — for everything else.

A cron schedule is the right tool when you want predictable, less frequent syncs
— for example, to align data collection with a source's off-peak hours or to
reduce API-call volume against a metered provider.

## Estimating API volume and cost

Sync frequency drives how many requests Monad makes to a source over time, which
is the main lever for staying within a provider's quota and controlling any
per-request cost:

- **Continuous (~10s) connectors** make the most frequent requests. Where a
  source charges per API call or enforces a tight quota, consider a cron
  schedule to cap request volume.
- **Scheduled (cron) connectors** already batch their work; adjust the cron
  cadence to trade freshness against request volume.
- **Push and queue connectors** don't poll, so their cost tracks data volume
  rather than a polling interval.

To bound outbound request *rate* independently of sync frequency, see
[API Rate Limiting](rate-limiting).