Blackout windows
Define windows when deploys are frozen for a service or environment.
Deliver
Deployment Windows
Freeze deploys when a release should not go out
Define maintenance and blackout windows when deploys should not happen, and let the deploy gate enforce them. A release that lands inside a frozen window is held, so a change-freeze is a rule the pipeline keeps rather than a calendar invite people forget.
- A change freeze is enforced by the gate, not dependent on someone remembering the calendar.
- Every held release has a recorded reason tied to the window that blocked it.
- Teams see which windows are active before they ship, so a blocked deploy is never a surprise.
The problem
Change freezes live in calendars and Slack threads. When a freeze is active, the only thing standing between a queued release and a frozen environment is whether someone remembers. One missed message and a release goes out during a holiday, a compliance window, or a critical maintenance period.
Without IntegraCI
- Freezes communicated as calendar invites and Slack messages
- Enforcement depends on engineers remembering in the moment
- No gate between a queued release and a frozen window
- Scoping a freeze to one service requires manual coordination across teams
With IntegraCI
- Windows defined once and enforced as policy as code
- The deploy gate holds a release without anyone needing to intervene
- Every held release is recorded with the window that blocked it
- Freezes scoped to exactly the services and environments they should cover
What you get
Enforced at deploy
The deploy gate holds a release that falls inside a frozen window.
Scoped freezes
Apply a freeze to the services and environments it should cover.
Visible to everyone
The window is published so teams know when shipping is paused.
How it works
- 1
Define the window
Set the blackout or maintenance window and what it covers.
- 2
Ship as usual
Teams keep working; the gate watches the calendar.
- 3
Held when frozen
A deploy inside the window is held until the freeze lifts.
How it stays governed
The same gates everyone passes, applied here.
Gated by policy
Deployment windows are evaluated as policy as code at the deploy gate. A release that lands inside a defined window is held automatically, so a change freeze is a rule the pipeline keeps rather than a calendar entry someone must remember to check before pushing.
Recorded, tamper-evident
Each gate decision writes once to a tamper-evident audit trail, including the window definition, the release that was held, and when the freeze lifted. You can show exactly why a deploy was blocked and when the hold ended, not just that it was.
Works with your stack
Connect the tools you already run.
Works with the CI/CD and deploy tooling you already run. IntegraCI evaluates the window at the gate rather than replacing your delivery pipeline.
- Akuity
- Amazon Web Services
- Buildkite
- CircleCI
- CNCF Tekton
- Drone CI
- Harness
- Jenkins
- Apple
- Argo Project
- AWS
- Cloudflare
- CNCF
- Coder
- Crunchy Data
- Daytona
- Env0
- +13 more
Who it’s for
Where teams reach for it.
Holiday and peak-traffic freezes
Define a blackout window for the days when you cannot absorb an incident. Releases queued during that period are held at the gate and proceed once the window closes, with no manual intervention required.
Regulated change-control windows
Compliance frameworks often require that production changes happen only within approved maintenance windows. Encoding those windows as policy gives auditors a recorded gate decision for every blocked and allowed deploy.
Coordinated multi-service releases
When a platform team needs to stabilize before downstream services ship, a scoped freeze on the affected services enforces the hold without a cascade of messages to every team.
Questions, answered.
Does IntegraCI replace our change management process?
No. You define when freezes apply and what they cover. IntegraCI enforces those rules at the deploy gate so the freeze is kept by the pipeline rather than relying on people to remember.
What happens to a release held during a window?
It is held at the gate until the freeze lifts. Once the window closes, the release can proceed through the normal gate checks.
Can a freeze be scoped to specific services or environments?
Yes. Each window is scoped to the services and environments it should cover, so a freeze on a production environment does not block deploys to staging.
Who can define or modify a deployment window?
Windows are defined as policy as code, so the same governance that controls your pipeline policies controls who can create or change a window.
Put Deployment Windows on your stack.
Request a demo, or read the docs to see how it fits the tools you already run.