What gets monitored
This page describes polling behavior, what a “change” means, and how org dependencies differ from catalog broadcasts. You’ll see cadence and health on each dependency in the app; you don’t need the API to verify scheduling.
Polling and scheduling
For each enabled monitored dependency, Intello enqueues sync jobs on a cadence derived from sync_frequency_hrs (subject to plan minimums and platform clamps).
A full sync attempt:
- Fetches the OpenAPI document.
- Parses and normalizes it.
- Writes a snapshot when successful.
- Diffs against the prior snapshot.
- Persists change events and evaluates alert rules.
If the document is byte-identical after normalization, no change events are emitted.
Baseline establishment
The first successful sync creates a baseline snapshot only. You will not see change events until a later sync observes a semantic difference. Plan onboarding accordingly—don’t expect alerts on day one unless the vendor moves quickly.
Partial monitoring modes
Dependencies can monitor:
full— entire OpenAPI surface.partial— restrict to selected domains or endpoints (paired with filter arrays on the dependency).
Partial modes reduce noise for orgs that only depend on a slice of a giant vendor spec.
Org dependencies vs provider broadcasts
| Aspect | BYO dependency | Provider subscription |
|---|---|---|
| Spec source | Your URL (or upload/default flows) | Intello-maintained provider specs |
| Scheduling | Per-dependency sync_frequency_hrs | Central provider pipeline + fan-out |
| Change feed | /api/dependencies/:id/changes | /api/provider-changes |
| Cutoffs | Generally full org history | May honor plan broadcast cutoffs |
Health and automatic pauses
Dependencies track consecutive failures. After enough failures, automatic scheduling pauses to protect workers—manual sync still works and resets health on success.
Details: Sync jobs and snapshots.