Why Deployment Changes Belong in Observability

Deployments and configuration changes are first-class evidence — not external context.

Problem

The first question in many incidents is "what changed?" — yet change data often lives outside the observability tools engineers use during investigation.

Current Practice

Deployment history sits in CI/CD systems, chat announcements, or ticketing tools — disconnected from metrics, logs, and traces on the investigation timeline.

Why It Breaks Down

Engineers lose minutes reconstructing change timelines. Automated correlation cannot link symptoms to causes when changes are invisible to the evidence model.

Architecture

Ingest deployment, rollout, and configuration change events as evidence alongside telemetry — aligned on service identity and timestamps.

Deploy

Rollout + config event

Identity

service.name alignment

Timeline

Shared timestamps

Evidence

Change + signal

Investigate

What changed?

Deployment changes enter the evidence model on the same timeline as telemetry.

Tradeoffs

Change ingestion adds integration work and noise if every minor config flip is treated as high-signal. Filter and classify changes by blast radius and production relevance.

Implementation

Connect Kubernetes deployment events, Helm releases, and feature-flag changes to the same resource identity used by OpenTelemetry signals.