TigerGate owns the schedule of every deployment and connection. You set it in the console; nothing in your Terraform needs to change when it does.

​
In-account deployments

​
The trigger

A timer in your environment starts the coordinator every 15 minutes:
PlatformTrigger
AWSEventBridge Scheduler (schedule_expression, default rate(15 minutes))
AzureA scheduled Container Apps Job (schedule_cron, default */15 * * * *)
Google CloudCloud Scheduler (schedule_cron, default */15 * * * *)
On-premA systemd timer (schedule, default *:0/15)
On each tick the coordinator asks TigerGate whether a run is due. If not, it exits within seconds. The 15-minute tick is therefore how quickly a due run or Run now is noticed, not how often data is scanned.

​
The schedule

Choose the schedule in the wizard or on the deployment’s Configuration tab: Every hour, Every 6 hours, Every 12 hours, Daily, Weekly (the default), Every 2 weeks or Every 30 days, or a custom interval from 1 hour to 30 days. The Configuration tab also offers Paused (Run now only). A deployment created before weekly became the default keeps its interval. With the defaults, scans run weekly, and every 30 days a scan reads everything again (see Full and incremental runs).
  • Run now, on the deployment’s row or its panel, is picked up at the next tick, within 15 minutes. To start the tick at once, run the command in the module’s run_now_command output.
  • Starting a run moves the next scheduled run one interval on.
  • Only one run is active per deployment. A second coordinator that starts while one is working exits at once.

​
Full and incremental runs

RunWhenWhat it reads
FullThe first run; every Full rescan every (days) (default 30, from 1 to 365); after a change to the classifier catalogue or to your custom data classes; whenever Incremental is offEvery object and table in scope
IncrementalEvery other runOnly new and changed objects and tables
The deployment’s Overview tab shows the Next run kind and, for a full run, the reason (for example first run, interval, catalog changed or custom classes changed). How an incremental run decides what changed:
  • Objects are compared with the state kept in your environment: the ETag or version id, the size and the modification time. New and changed objects are read; unchanged ones keep their earlier classifications.
  • Deleted objects are recorded as removals: their classifications are dropped and the change appears under Activity → Data Changes.
  • Very large S3 buckets with S3 Inventory configured are listed from the inventory instead of the list API.
  • Database tables are compared by their last-altered time or statistics, plus a primary-key or timestamp high-water mark where one exists. A table that cannot be compared is read in full on each run.
  • File shares are tracked per file: NFS by its change attribute, SMB by size and modification time.
A store’s totals always equal the sum over its current objects, however many runs it took to read them.

​
Run limits

  • Run time limit (hours) on the Configuration tab (default 24). Shards still open after it end the run as partial, and their stores are listed with the reason.
  • A run with no progress for 6 hours is closed as failed (abandoned).

​
Per datastore

On a datastore’s Actions menu (on the Datastores page or the datastore’s full page):
  • Rescan now reads the store in full in the deployment’s next run.
  • Auto-Scan On, Off or Use account schedule. Off skips the store’s content; On reads it even when the deployment’s name scope excludes it.
  • Scan Priority High, Normal or Low. Higher-priority stores are planned first.
On the Datastores list, Select gives the same Rescan, Auto-scan on and Auto-scan off actions for many stores at once.

​
Hosted SaaS and warehouses

TigerGate runs its own scheduler for SaaS and warehouse connections. Each connection has two intervals on its Configuration tab under How often: Inventory, which discovers the connection’s datastores, and Content, which reads them. Each offers Every hour, Every 6 hours, Every 12 hours, Daily, Weekly (the default), Every 2 weeks or Every 30 days, or a custom interval. A connection created before weekly became the default keeps its intervals.
  • A connection gets a weekly inventory schedule when it is saved or passes its connection test.
  • Content is read at its own interval. An inventory run does not make content due early.
  • A datastore that has never been read is read once it is discovered.
  • Run now runs discovery, then reads what changed.
  • Rescan now reads every datastore of the connection in full, ignoring the change feeds. A large tenant can take hours and uses the provider’s API allowance.
As for in-account deployments, scans run weekly by default, and every 30 days a scan reads everything again. Under Hosted scanning on the same tab:
SettingDefaultMeaning
Content readFull contentFull, or Sampled (a bounded sample of each item).
IncrementalOnRead only what the provider’s change feed reports since the last run. Off reads everything every run.
Full rescan every (days)301 to 365. Also catches what no change feed reports.
Jobs in flightThe deployment default1 to 16. Lower it if the provider rate-limits the connection.
Keep masked samplesOnOff drops masked samples before anything is stored. Needs an owner or admin. Disabled while your organization’s Data samples policy is Omitted.
A run is also full after a classifier catalogue or custom class change, and the store is listed again in full when the provider rejects the stored change cursor. Throttling. TigerGate honours each provider’s rate limits (HTTP 429 or 503 with Retry-After, and the provider’s own quota errors) on that connection only, so one tenant never pauses another. A pause longer than five minutes ends the read: the remaining items stay pending, the connection is marked throttled, and the datastore is read again when the pause ends, without waiting for its next interval.