Sync model

Every data source runs the same pipeline: authenticate, collect, validate, create evidence, map evidence to controls, then hand the results to findings and linking. This page explains the schedule that drives it, the statuses you see in the list, and what one successful run leaves behind.

Sync frequencies

Pick the frequency in the connect dialog under Sync frequency, or change it later from the detail drawer's Sync frequency row (an inline select with Hourly, Daily, and Weekly; admin or editor role required). Several provider dialogs do not show a frequency field and connect at daily: Cloudflare, DigitalOcean, Confluence, Databricks, Datadog, Detectify, and GitHub. You can still change those afterwards in the drawer.

Noru continuously looks for sources whose next sync time has passed and whose status is Connected or Error. A Disconnected source is never picked up automatically; see Statuses. If a source is in Error, it is retried automatically, sooner than the configured frequency. If a sync for the same source is already running or waiting to run, a second one is not started.

Run a sync now

Each row in Data Sources has a refresh button. It starts a sync immediately that behaves exactly like a scheduled run. The button is disabled while the status is Syncing; a Cancel button and a progress bar with the run's current step appear while it runs.

Statuses

When a source is Disconnected, or in Error with a stored reauthentication reason, the row shows an orange Needs reauthentication line with the reason and a Reauthenticate button. Providers that classify their own auth failures this way include Linear, GitLab, Google Workspace, the Microsoft family, HaileyHR, JungleMap, Cloudflare, DigitalOcean, and GitHub. AWS, Google Cloud, Datadog, Detectify, Databricks, and Confluence do not distinguish an expired credential from other failures, so an expired credential there shows as Error and is retried automatically until you fix it.

Three validation outcomes are logged as warnings but leave the source Connected: "Data validation failed", "No organization data collected", and "No evidence data collected". Check Sync history if a source looks healthy but is producing nothing.

Sync history

The detail drawer has a Sync history section (collapsed by default, with a count badge). Each run records a status of success or error, a message ("Sync completed successfully" or the error text), items processed, failures, control mappings generated, and duration. A run that does not finish in a reasonable time is timed out and recorded as an error.

What a sync produces

The run's summary message reads "Successfully synced N items and generated M control mappings". Transient provider errors such as rate limits are retried automatically inside the run before it is marked failed.

After the sync

Once evidence is written, two non-fatal steps run:

1. Findings are persisted for the integration: new ones created, existing ones updated, and ones no longer reported marked resolved.
2. Post-sync linking connects scan findings to assets, links findings to risks that were pre-created for them, registers certificate domains discovered in evidence, records Google Workspace third-party grants, refreshes the privacy data map for connectors that have one, proposes grant attributions to the review queue, and runs privacy drift detection.

Control mappings are made per provider, keyed on evidence type and name. Separately, cloud-only organizations get physical-infrastructure evidence items marked not applicable ("GCP/AWS handles the perimeter"); that comes from your organization profile, not from a sync.

A sync does not mark any control implemented and does not replace review. It proves configuration and inventory facts at collection time; it cannot prove that a process operates or why a choice was made. See control status and coverage for how mapped evidence feeds status.

Related

• Under the hood: Sync model and job scheduler
• Under the hood: Evidence lifecycle and integrity
• Troubleshooting
• Reference: Statuses