Deployment Availability

Control Exactly When Deploys
Can — And Cannot — Happen

Block deployments per project or across your entire account during incidents, change freezes, and planned maintenance. No surprise deploys when the stakes are highest.

Per-project and account-wide rules
Audit log of every block
Enforced across UI, API, and CLI

Last updated on 22nd June 2026

Availability Rules
Friday Change Freeze
Active · Project
Black Friday Window
Active · Account
On-call hours (Mon–Fri 18:00–08:00)
Scheduled
Deploy to production
Blocked

Deployment Availability lets you define windows when deployments are blocked — at the project level for individual teams, or account-wide for company-spanning rules. Every attempt to deploy during a block is rejected and logged, so change freezes, incident response, and compliance windows are enforced automatically across the UI, API, and CLI.

The Problem with Honor-System Deploy Freezes

Slack announcements and calendar invites don't stop someone from pushing during a freeze, an incident, or a peak-traffic event.

CHANGE FREEZE Slack: "no deploys today" Calendar: Black Friday No technical enforcement ⚠ Someone pushes PRODUCTION ❌ Surprise deploy ❌ Outage at peak ❌ Failed audit Policy without enforcement is a liability, not a safeguard

Freezes communicated only in chat or calendars get bypassed at the worst possible moments — exactly when an unexpected deploy can cause the most damage.

Deployment Availability — Enforced at the Platform Layer

Define rules in DeployHQ and every deploy attempt is checked against them — from any interface, by any team member.

DEPLOY ATTEMPTS Web UI API CLI Auto-deploy webhook AVAILABILITY RULES Project: Friday freeze Account: Black Friday Account: On-call hours ⚡ Enforced + logged OUTCOME ✓ Deploy blocked ✓ Reason shown ✓ Audit trail ✓ Compliance pass

How It Works

Two scopes, one consistent enforcement model.

1
Text icon

Define the Window

Pick a start and end time, recurrence, and a reason. Rules can be one-off, weekly, or open-ended for incident response.

2
Server icon

Choose the Scope

Apply per project for team-specific freezes, or account-wide so compliance and ops can lock the whole estate.

3
Shield icon

Enforce Automatically

Every deploy attempt — from UI, API, CLI, or auto-deploy webhook — is checked against the rules and rejected if blocked.

4
Check icon

Audit and Review

Every blocked attempt is logged with the rule that triggered it, who tried, when, and why — ready for audit and post-incident review.

Why Use Deployment Availability?

Stop relying on chat announcements and good intentions to keep production stable during the riskiest windows.

Shield icon

Compliance Without Friction

Encode change-management windows as rules instead of policies. SOC 2, ISO 27001, and PCI auditors get a clean log of every deploy attempt and every block.

Server icon

Two Scopes, One Model

Project owners can freeze their own service. Account admins can freeze everything at once. Both run through the same enforcement layer.

Check icon

No Bypass Surface

The same rules apply to deploys triggered by the API, the CLI, scheduled jobs, and Git webhooks. There's no back door to forget.

Zap icon

Pairs with Scheduled Deploys

Combine with Scheduled Deployments to queue work for the next open window. Engineers don't have to babysit the clock.

Getting Started

Set up availability rules in minutes

Check mark

Open Availability Settings

Account-wide rules live under Account Settings → Availability. Project-scoped rules sit under each project's Settings tab.

Check mark

Add a Rule

Set a window, recurrence, and reason. Rules apply immediately — no redeploy needed.

Check mark

Review the Audit Log

Every block is recorded. Filter by rule, project, or person for incident reviews and compliance reports.

Read the documentation →
AVAILABILITY RULE Scope: Account-wide · all projects Window: Nov 28 00:00 → Dec 02 23:59 UTC Reason: Black Friday — peak traffic Status: Active

Frequently Asked Questions

How is this different from Deployment Checks?

Deployment Checks validate a single deploy — running SSH commands, HTTP probes, or vulnerability scans before or after the deploy runs. Availability rules sit one layer earlier: they decide whether the deploy is even allowed to start, based on time-based and scope-based policy.

Can I override a block in an emergency?

Account admins can disable or edit any rule. Every override is logged with the user, timestamp, and reason — so emergency deploys are still fully traceable for post-incident review and audit.

Does the block apply to API and CLI deploys too?

Yes. Availability rules are enforced at the deployment service level, so every entry point — web UI, REST API, CLI, scheduled deploys, and Git webhooks — is subject to the same check. There's no bypass surface.

Can finance or compliance staff set account-wide rules without project access?

Yes. Account-wide availability is a separate permission. You can grant compliance or operations staff the ability to manage account rules without giving them deploy or project permissions.

Does this work with Scheduled Deployments?

It pairs naturally. Queue a deploy with Scheduled Deployments, and Availability rules will reject the execution if it falls inside a blocked window — letting you batch deploys safely for the next open window.

Stop surprise deploys before they happen

Encode change freezes and peak-traffic windows as enforced rules — not chat messages.

10-day free trial • No setup fees • Cancel anytime

Get started today for just $9/month

That's unlimited deployments and 3 projects.

Start your free 10 day trial