Release attribution

Release attribution is the reason GreenSlope exists. When an error spikes or a latency SLO starts burning, the dashboard doesn't just tell you that something broke — it tells you which deploy introduced it.

This page is the mental model for how that works, and why your instrumentation needs to set greenslope.release.id on every span.

The three inputs

Attribution needs three things to be in place:

1. A release ID on every span. Set as the greenslope.release.id resource attribute. Usually a git SHA.
2. A change event that records "release X deployed to environment Y at time T". Published by your CI, Vercel, or the REST API.
3. A commit graph we can walk from release X back to its parent. Provided by the GitHub integration.

Given those three, when the error rate for service.name=web spikes on a specific release ID, we can name the commit range that was added — and, in the common case, the single PR.

Why a release ID separately from service.version?

service.version is for humans — 2026.4.21, v1.8.0. It's what you show in your status UI. Two different builds can legitimately share a human-readable version during a deploy.

greenslope.release.id is for machines. It needs to be stable and unique per build, so the dashboard can bucket spans by the exact code that was running. A git SHA is the simplest choice that satisfies both.

How change events fit

A span tells us "this ran on release X". A change event tells us "release X went live at 14:02 UTC on production". Put them together and we can render the timeline view:

14:00 ─────────────────────── deploy 7fa9c21 ────────────── 14:04
       │                          │                           │
       │ error rate: 0.1%         │ error rate: 3.8%          │
       │                          └ ← regression introduced   │

Without the change event, we'd know errors spiked but not because of what. Without the resource attribute, we'd know a deploy happened but not which spans belonged to it. You need both.

See Change events for how to publish them — GitHub Actions, Vercel, or the REST API.

Rollback detection

Because release attribution is tied to the commit graph, GreenSlope knows that release c3a201d is an ancestor of release 7fa9c21. That means we can detect a rollback automatically: if you redeploy a previous release's SHA, the dashboard shows it as a rollback, not a new release.

What breaks attribution

Attribution silently fails when any of the following happen:

• Missing greenslope.release.id on some spans but not others. The service looks healthy on the unreleased-ID spans, dashboard-wide stats get noisy. Guard against this with a startup assertion.
• Release ID isn't stable. If you generate a new UUID per process start, every span has a unique release ID and bucketing is useless. Use the git SHA.
• Change event missing. Without it, we see spans from a new release but don't know when it went live.

All three show up in the dashboard as "missing release data" warnings on the Doctor page.