Sync schedules & freshness
How Kimo keeps data fresh: default cadences per connector type, incremental vs full syncs, per-table overrides, freshness SLAs and what happens when a sync fails.
Every source has a sync schedule. A sync fetches rows that changed since the last run and merges them into Kimo’s cache. Dashboards and alerts always show when their data was last refreshed, so nobody has to guess whether a number is stale.
Default cadences
| Connector family | Default | Minimum | Method |
|---|---|---|---|
| Databases (Postgres, MySQL…) | 15 min | 5 min | Cursor on updated_at |
| Warehouses (Snowflake, BigQuery…) | 1 h | 15 min | Live or cached |
| Billing (Stripe, Paddle…) | 1 h | 15 min | Events API |
| CRM (HubSpot, Salesforce…) | 1 h | 15 min | Change cursor |
| Ads & SEO (Google Ads, GSC…) | 6 h | 1 h | Lookback window |
| Streams (Kafka, AIS, ADS-B) | Continuous | — | Consumer group |
| Files (CSV, Sheets) | 24 h | 1 h | Full replace |
Incremental, full and lookback syncs
- Incremental — only rows whose cursor moved. Fast and cheap; the default for most tables.
- Full — re-reads the whole table. Used for small tables without a reliable cursor and for the first sync.
- Lookback — re-reads a sliding window (e.g. the last 3 days) to catch late-arriving data from ad platforms.
Per-table overrides
Open a source, select a table and choose Schedule. A common pattern is syncing a large events table every 5 minutes while leaving reference tables on a daily full sync. Overrides can also be declared in code:
source: productionschedule: every 15 minutestables: events: schedule: every 5 minutes cursor: created_at plans: schedule: daily at 02:00 UTC mode: full invoices: detect_deletes: trueFreshness SLAs
Set a freshness SLA on a model (for example "revenue must be less than 2 hours old"). If the SLA is breached, tiles show an amber "stale" badge with the last successful sync time, and the model owner receives an alert. SLAs are the recommended way to monitor pipelines because they measure what users actually see.
When a sync fails
- 1Automatic retries
Transient errors (timeouts, rate limits, 5xx) retry with exponential backoff: 1, 2, 4, 8 then 16 minutes.
- 2Source marked degraded
After five failed attempts the source turns amber in Connectors and the owner is notified by email and Slack.
- 3Data stays available
Dashboards keep serving the last good data with a visible "last synced" timestamp. Kimo never shows half-written syncs.
Freshness vs. cost
Faster is not always better. Every sync consumes API quota at the provider and compute in Kimo, and ad platforms in particular rate-limit aggressive polling. A good rule of thumb is to sync twice as often as people look: if the revenue review happens every morning, hourly is plenty; if support leads watch a live queue, 5 minutes makes sense. The Usage page shows sync minutes per source so you can spot the expensive ones.