Skip to main content

Change Events

Cloudaware CMDB detects and normalizes changes to configuration items and their relationships. Change events form the bridge between raw discovery deltas and workflows, notifications, and downstream tools.

Event Types​

Typical CMDB change events include:

  • Create – a new CI appears (for example, a new VM, database, or load balancer is provisioned).
  • Update – configuration or metadata on an existing CI changes (size, image, tags, ownership, security settings, coverage flags such as “backed up” or “monitored”).
  • Delete/Retire – a CI is terminated or otherwise marked as decommissioned in CMDB.
  • Relationship change – dependencies between CIs change (for example, instance ↔ volume, load balancer ↔ target group, application ↔ database).
  • Lifecycle/state change – runtime state transitions (stopped, started, restarted, failed) where supported by the source.

Each event is associated with a specific CI, event time, source system, and (where available) before/after values for key fields.

Event Sources​

CMDB change events originate from multiple ingestion paths:

  • Cloud control planes – periodic discovery jobs for AWS, Microsoft Azure, Google Cloud, and other providers compare current API responses to the last known state and emit events for detected changes.
  • Breeze Agent – OS‑level changes such as installed packages, services, users, filesystem mounts, or configuration files can generate CMDB updates and corresponding events.
  • Third‑party integrations – monitoring, ticketing, and security tools may update fields or relationships (for example, linking incidents or vulnerabilities to CIs), which appear as updates in CMDB.
  • Interactive changes – administrators can update CMDB records directly (for example, ownership, criticality, or application mappings), which are tracked as changes and audited.

Consuming Events​

Change events can be used to drive automation and notifications:

  • Build CMDB queries that identify high‑risk or high‑value changes (for example, security‑sensitive resources in production).
  • Use Cloudaware automation and webhooks to publish change events to external systems, such as ITSM tools or SIEMs. See Webhooks & Events for webhook concepts.
  • Feed events into Change Management workflows so that infrastructure changes can be validated against approvals and maintenance windows before actions proceed.

Downstream systems should treat event IDs and timestamps as the source of truth for “what changed” and when, and use CI identifiers to correlate events with other data (incidents, cost, compliance findings, etc.).