​

Configuration Drift

Configuration Drift is for comparing intended infrastructure state with live cloud state over time. It is more operationally demanding than static analysis, so treat it as a second-phase workflow after your Git and cloud integrations are already healthy.

​

What It Depends On

To get value from drift monitoring, you need:

• Repositories that represent intended state
• Cloud integrations that represent live state
• Monitoring preferences that tell Cloudgeni how often to check

​

How The Current Product Is Structured

The app splits drift work across a few surfaces:

• Onboarding and configuration for setup
• Drifts for triage
• Scans for run history
• Remediations for PR-backed follow-up

The backend also treats drift scans as pipeline-backed runs, not as a one-off polling job.

​

Important Current-State Detail

The current product surface is a little more split than the older docs implied. Repository setup and monitoring preferences are part of the main setup flow, while ongoing connection management lives under the drift configuration area. Document drift as a composed workflow, not as a single wizard that does everything in one screen.

​

What The Findings View Supports

The drift experience supports:

• Triage by severity and status
• Grouped and raw views
• Scan history
• Bulk actions
• Remediation handoff for selected findings

Bulk remediation is most useful when the selected drifts belong to the same repository, because the result still needs a coherent PR path.

​

When To Use It

Use Configuration Drift when:

• Your repositories are already the source of truth
• You care about divergence after deployment
• You want a recurring operational check instead of a one-time repository scan

Do not make this your first Cloudgeni workflow unless you already trust the repository-to-cloud mapping.

​

Related Pages