Deployment tracking that tells you if a release is healthy

What is deployment tracking?

Deployment tracking means recording every release and change to a production system and connecting it with the telemetry that shows how the system behaves. A deployment event typically carries the service, version, environment, commit, author and timestamp. Change tracking extends the same idea to configuration updates, feature flag toggles, infrastructure changes and database migrations.

Without this information, every incident starts with the same question in the chat channel: did anybody deploy something? Engineers search CI logs, scroll through Git history and ask around. With deployment tracking, the answer is on every chart as a release marker, and the platform can already tell you which change lines up with the start of a problem.

Why change tracking matters

Changes are one of the most common triggers of production incidents. That is not an argument for releasing less often; frequent, small releases are easier to reason about and to roll back. It is an argument for making every change visible and measurable.

When changes are tracked, three things improve. Detection gets faster, because a regression can be attributed to a specific release instead of being treated as a mysterious anomaly. Recovery gets faster, because rolling back the right version is usually the quickest fix. And delivery gets safer, because teams can validate a release against real production signals before rolling it out to everyone.

Signals for before/after comparison

To decide whether a release is healthy, compare the new version with the previous one under similar load. The most useful signals are:

• Error rate per endpoint, including new exception types that did not exist before.
• Latency percentiles such as p50, p95 and p99, because averages hide tail regressions.
• Throughput, to spot traffic that silently stopped reaching an endpoint.
• Resource usage like CPU, memory, garbage collection and connection pools, which reveal inefficiencies early.
• SLO burn rate and, where available, business KPIs like conversion or successful payments.

Comparing these per version rather than per time window matters during progressive rollouts, when old and new versions serve traffic at the same time.

How Obseria tracks deployments and releases

Obseria accepts change events from any source: a step in your CI/CD pipeline, the Obseria CLI, the API, Kubernetes rollout events or GitOps controllers. If your services already set the OpenTelemetry resource attribute service.version, Obseria detects new versions automatically from the incoming telemetry, with no extra integration.

Each release appears as a marker on dashboards, service pages and traces. The release view compares golden signals, new error groups and resource usage between versions and highlights statistically significant differences. You can query the same data in OQL:

fetch spans | filter service == "checkout" | summarize p95(duration), count(), by:{service.version}

Release validation turns this comparison into a gate. You define criteria, for example no new error groups, p95 latency within 10 percent of the previous version and no SLO burn alert. Your pipeline queries the result via API or CLI and continues or stops the rollout. If a regression is detected, an Obseria Automation workflow can roll back automatically. Obseria Intelligence uses the same change events when correlating anomalies, so a problem that starts right after a release names that release as a candidate cause.

Deployment tracking best practices

1. Set service.version everywhere. It is the simplest and most reliable way to attribute telemetry to a release.
2. Track more than deployments. Configuration and feature flag changes cause incidents just as often.
3. Release in small steps. Canary or progressive rollouts make before/after comparison meaningful and limit impact.
4. Automate the gate. Let the pipeline decide based on agreed criteria, not on someone watching a dashboard.
5. Link releases to code. Commit and pull request references shorten the path from symptom to fix.