Freezes and approvals
When not to ship, and who says yes.
Deploy freezes
A freeze blocks deployments to an environment for a window.
Settings → Deployments → Freezes.
| Field | Notes |
|---|---|
| Environments | Usually production |
| Window | Start and end |
| Reason | Write a real one |
| Services | All, or specific ones |
| Override | Who may deploy anyway |
Typical uses: a sales event, a compliance window, a public holiday when nobody is around to fix a bad deploy.
A freeze is enforced at the pipeline gate. A deploy run outside AccelerUp — by hand, or by a CI job that does not check — is not stopped. Freezes are organisational agreements that AccelerUp enforces where it can see them.
Override
Some deploys must happen during a freeze: the fix for the incident that started during it.
Override is role-gated, requires a reason, and is audited. It is not a lock — it is a speed bump with a name attached, which is the correct design for something that must remain possible.
Approvals
An approval requires a named person to say yes before a deploy proceeds.
Settings → Deployments → Approvals defines which environments and services need one, and who may give it.
The approval inbox
Delivery → Approval inbox lists what is waiting on you, with the changeset and the risk score.
Read the changeset before approving. An approval that is always given immediately is a delay, not a control, and everyone involved knows it.
Approvals and freezes together
The usual arrangement:
| Environment | Freeze | Approval |
|---|---|---|
| Staging | No | No |
| Preprod | Rarely | No |
| Production | Windows | Yes, for high-risk services |
More than that and people route around it, which leaves you with no control and no record.
Related
Where this behaviour lives: frontend/src/app/deployments/freezes/, frontend/src/app/deployments/approvals/. 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.