Compare Infrastructure Configuration Changes

Identify exactly what changed in your infrastructure and understand how it affected resource health. With the Configuration Compare view in Infra Explorer, you can review configuration versions side by side and correlate changes with health status over time.

Use this feature to reduce investigation time and focus on changes that impact behavior.

Why this matters

Configuration changes are a common cause of production incidents. Identifying the exact change that triggered a failure can be time-consuming—especially when resources emit frequent system updates.

The Configuration Compare view helps you:

• See exactly what changed between configuration versions
• Understand when the change occurred
• Determine whether the change coincided with health degradation
• Ignore system-generated updates that do not affect resource behavior

Instead of manually scanning large configuration files, you can immediately connect configuration updates to system behavior.

Meaningful updates vs keep-alive events

Infrastructure resources generate frequent update events. Not all updates represent real configuration drift.

To reduce noise and keep version history actionable, Infra Explorer distinguishes between meaningful updates and keep-alive events.

Meaningful updates

Meaningful updates change how the workload runs, behaves, scales, or executes.

These include changes to:

• Resource specification fields such as spec
• Metadata fields that affect behavior, such as labels and annotations

Only meaningful updates generate new configuration versions and appear in the version selector.

Keep-alive events

Keep-alive events reflect routine system or status updates that do not affect functional behavior. These include changes to system-managed fields such as:

• ownerReferences
• managedFields
• resourceVersion
• creationTimestamp
• uid
• deletionTimestamp
• deletionGracePeriodSeconds

Keep-alive events do not create new configuration versions but appear in lifecycle activity for visibility. This approach ensures configuration history reflects only meaningful behavioral changes.

Example: meaningful update vs keep-alive update

Create (16:00)

A resource is first detected and registered.

• The version selector shows Current (16:00) and V1 (16:00)
• Lifecycle activity shows Create (16:00)

Meaningful update (16:05)

A configuration field changes:

metadata.labels.foo: null → "bar"

This update:

• Creates a new configuration version V2 (16:05)
• Appears in the version selector
• Displays differences when comparing V1 and V2
• Shows Update (16:05) in lifecycle activity

Keep-alive update (16:10)

A system-managed field changes:

metadata.resourceVersion: "123" → "124"

This update:

• Does not create a new configuration version
• Does not appear in the version selector
• Appears as a keep-alive lifecycle event

The version history remains focused on meaningful configuration changes.

Compare configuration versions

Review two configuration versions side by side to see exactly what changed. By default, Infra Explorer compares:

• The current configuration
• The most recent previous meaningful version

The comparison view highlights:

• Added fields
• Modified values
• Removed configuration entries

Enable Show only differences to focus exclusively on changed sections.

Version retention

• Versions are retained for 14 days
• Only versions generated from meaningful configuration changes appear in the version selector
• The current configuration is always available

Correlate configuration changes with health

The configuration timeline aligns version changes with resource health. Resource health is derived from attached health policies.

Health states

Healthy: All enabled health policies report a healthy state
Critical: At least one enabled health policy reports a critical condition
Unmonitored: No health policies actively monitor the resource

If a resource enters a Critical state at any time during a day, that day appears as critical in the timeline. This helps you identify instability even if the issue was temporary.

By aligning configuration changes with health, you can:

• Determine whether a configuration update preceded a health degradation
• Confirm that a deployment restored the resource to a healthy state
• Identify health issues that occurred without configuration changes

Example investigation workflow

Use configuration comparison and health context together to investigate unexpected behavior:

1. A resource enters a Critical state
2. Open the resource and go to Configuration
3. Compare the current configuration with the previous version
4. Review highlighted differences in spec, labels, limits, or other behavioral fields
5. Check the health timeline to determine whether the configuration change preceded the degradation

This workflow helps you quickly connect configuration updates to system behavior and identify likely root causes without manually reviewing logs or full configuration manifests.