Deployment history
Every deploy, what was in it, where it went, and what happened afterwards.
Delivery → Deployments → History is the record of every deploy.
A deployment
| Service and environment | What went where |
| Version | Tag, commit, build number |
| Who and when | Triggered by, started, finished |
| Status | Running, succeeded, failed, rolled back |
| Changeset | The commits and pull requests in it |
| Health score | What happened in the window afterwards |
| Servers | Which boxes, in what order |
The changeset
The Changes tab lists the commits and pull requests between this deploy and the last one to the same environment.
This is the difference between "4.18.2 deployed" and "4.18.2 deployed, containing these nine commits, four of which touch checkout". It is what makes the deploy actionable during an incident.
Commit repositories can be overridden per deploy, for services built from a repository whose name does not match.
Post-deploy health score
After a deploy, AccelerUp scores the window that follows:
| Score | Means |
|---|---|
| Healthy | No new error groups, no incidents, no rate spike |
| Suspect | Something moved. Worth a look |
| Bad | New error groups or an incident |
Inputs: new error groups, incidents opened, and error-rate spikes.
The score is posted to Slack, so a bad deploy announces itself rather than waiting to be noticed.
A health score is a correlation, not a verdict. It says what happened after the deploy — deliberately never that the deploy caused it. During a busy hour several things change at once and the honest statement is the temporal one.
The unified timeline
Delivery → Deployments → Timeline puts deploys, releases, incidents, configuration changes, flag flips and Cloudflare traffic shifts on one axis.
This is the page to open when something broke and you do not yet know what changed.
Rolling back
From the deployment: roll back to the previous version, or to the last known good per server.
A rollback is itself a deployment, with its own changeset and its own health score. It is not a special case, and it is not invisible.
Risk score
Each deploy carries a heuristic risk score from the size of the changeset, the files touched, the time of day and the recent failure history of that service.
Use it to decide how closely to watch — not as a gate. A high-risk deploy on a Tuesday morning is fine; the same one at 17:45 on a Friday is a choice.
Where this behaviour lives: frontend/src/app/deployments/, backend/internal/service/deploy_svc.go. If the code and this page disagree, the code is right — please fix the page.
Part of Delivery — Deployments, pipelines, releases and everything that ships code.