Deploying a release

Once a release is wrapped up and ready, the last thing left is to ship it — to get the new version out to production where your users are. That final cut-over has its own place on the release page: the Deploy section. This article walks through what you'll see there, step by step, so you always know where a deploy is, what's happening on its own, and the couple of moments where a person needs to decide something.

The Deploy section is designed to be watched. The steps advance themselves as the deploy progresses, and the section updates live — you don't refresh, and you don't drive it from here. Your job is mostly to follow along and to notice the one place that asks for a human call.

#Before it starts

Until a release actually begins deploying, the Deploy section simply reads Not deployed yet. That's the normal resting state for a release that's still being planned, worked, or wrapped up — there's nothing to watch here yet.

A deploy kicks off only after the release has been reviewed and wrapped. When it does, this section comes to life with a progress strip.

#The five steps

A deploy moves through five steps, shown as a strip near the top of the section. Steps already finished are filled in, the current step is highlighted, and the steps still ahead are dimmed:

Merging → Deploying → Smoke-testing → Monitoring → Shipped

Here's what each one means and what, if anything, happens on your side.

#Merging

The release's changes are being merged into the main line of code. This is the point of no return — everything up to here can be reworked, but a merge is what commits the release to shipping.

What you do: this is one of the two moments a person is in the loop. The merge is started by you or a teammate (never silently), after any final go-ahead. Once it's done, the section shows the merge — a short code reference and who merged it — and moves on by itself.

#Deploying

The merged code is now being rolled out to production. Depending on how your project is set up, this either happens automatically the moment the merge lands, or a teammate performs the rollout by hand. Either way, this is the step where the new version actually reaches your live site.

What you do: watch. There's nothing to click — the step advances on its own once the new version is live.

#Smoke-testing

A quick automatic health check confirms the freshly deployed site is actually up and responding — the software equivalent of "does it turn on?" It's called a smoke test, and it's over in moments.

What you do: watch. If it passes, you'll see Smoke tests passed and the deploy continues to monitoring. If it fails, the deploy stops here and asks for a decision — see When a check fails below.

#Monitoring

The progress strip at Monitoring, showing the monitored evidence line.

Passing the first health check isn't quite the finish line. The deploy now watches production for a short window — repeatedly re-checking that the site stays healthy after real traffic starts hitting it. The section shows how many checks have run and how long the window is, for example Monitored: 5 checks, 10-minute window.

What you do: watch. This is a good moment to keep an eye on your own dashboards too — error rates, exceptions, anything you normally watch after a change. If every check in the window passes, the deploy finishes.

#Shipped

The release is live and has held up through its monitoring window. You'll see a green Shipped banner, the whole strip filled in, and — when available — a View deployed release link that opens the deployed version.

What you do: nothing more. It's shipped.

#Reading the details line

Underneath the strip is a row of facts about the deploy, filled in as it goes:

Merged abc1234 by Sam — the merge that started it, and who did it.
Smoke tests passed (or failed) — the result of the health check.
Monitored: 5 checks, 10-minute window — how much watching happened.
updated 12s ago — how long since this section last refreshed. Because the section updates live, this usually stays small. (For more on what "live" and "updated Xs ago" mean, see Understanding the Live indicator.)
View deployed release — a link to the deployed version, once there is one.

#When a check fails

Most deploys sail straight through. But a health check can fail — the site comes back with an error, or responds too slowly — and when that happens the deploy stops on purpose rather than pretending everything's fine.

You'll see a Rollback needed banner: "The release is live but a check failed. Someone needs to decide whether to roll back." The step where it stopped is tinted to match, so the strip itself reads as stopped here, and the deploy does not advance to Shipped.

This is deliberately a human decision — the app won't roll back or retry on its own. This is the second moment a person is in the loop. Someone on your team looks at what went wrong and chooses a path:

Investigate and fix forward — often the site is up but something small is off (a setting, a cache, a missing asset). Sort it out and re-check.
Roll back — undo the release so production returns to the previous version.

Until that decision is made and acted on, the release stays in this stopped state. That's the safe default: a deploy that didn't fully pass is never quietly marked as shipped.

#The short version

The Deploy section on a release is where you watch it ship — it updates live and you don't drive it from here.
Not deployed yet is the resting state before a deploy begins.
Deploys move through Merging → Deploying → Smoke-testing → Monitoring → Shipped, shown as a progress strip.
A person is in the loop at exactly two points: starting the merge, and deciding what to do if a check fails. Everything in between you simply watch.
A green Shipped banner means it's live and held up through monitoring.
A Rollback needed banner means a check failed and the deploy stopped for a human decision — nothing ships silently on a failed check.