Identify exactly what changed in your infrastructure and understand how it affected resource health. With the Configuration Compare view in **Infrastructure Explorer**, 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, 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, **Infrastructure 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:

```text
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:

```text
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, **Infrastructure 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.

Aligning configuration changes with health helps you:

- 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
1. Open the resource and go to **Configuration**
1. Compare the current configuration with the previous version
1. Review highlighted differences in `spec`, labels, limits, or other behavioral fields
1. 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.

## Next steps

Track and optimize your infrastructure telemetry ingestion by reviewing [Data usage](https://coralogix.com/docs/user-guides/infrastructure/infrastructure-explorer/infra-data-use/index.md).

## Related resources

- [Explore your infrastructure](https://coralogix.com/docs/user-guides/infrastructure/infrastructure-explorer/explore-infra/index.md)
- [Ownership](https://coralogix.com/docs/user-guides/infrastructure/infrastructure-explorer/ownership/index.md)
- [Health overview](https://coralogix.com/docs/user-guides/infrastructure/infrastructure-explorer/health-overview/index.md)