Skip to main content
The deploy gate answers one question from your CI/CD pipeline: is it safe to deploy this service right now? It looks at the service’s SLOs, burn rates, active critical alerts and any freeze you set, and it refuses when it cannot be sure.

​
Call the gate from your pipeline

Go to Settings, open the API Keys tab, click Generate API Key, name it and tick the api:read scope. Overriding a gate also needs api:write. Then ask about one service. The service name is the one your SLIs use, or the service linked on a synthetic check. A pipeline step can fail on anything other than 200:
GET /api/deploy-gate returns every gated service at once. It always answers 200, so read each service’s allowed flag. Add ?mode=simple to either call for a short answer with only the allowed flag.

​
What the response means

The body also carries advisories (notices that do not refuse the deploy, such as a suspended SLO), slos and active_incidents. A deploy is held for any of these:
  • Error budget low. The remaining budget is below the threshold, 10% unless you set another in a deploy policy.
  • Error budget unknown. The SLO has never been measured. An unmeasured budget is not treated as a full one.
  • SLO tracking degraded. The data source is unreachable or answering nothing, so the number cannot be trusted. See Set up SLOs.
  • Fast or slow burn rate. The SLO is burning budget faster than its alert thresholds.
  • Active critical incidents. Critical alerts for the service are still active or acknowledged.
  • Deploy freeze. You froze the service until a set time.
The gate only evaluates SLOs that measure the service directly, or that are backed by a synthetic check linked to it. By default it gates services you actually deploy, so an SLO for something you never ship does not block anything. Set Gate deploys on this SLO to Always gate deploys to gate a service before its first deploy.

​
Four ways to unblock a gate

In the order you probably want them:
1

Fix the data source

For a degraded or unknown SLO, restore the data source. The gate clears by itself on the next successful computation, with no further action. This is the intended path.
2

Suspend the SLO

Open the SLO under SLOs and click Suspend. A suspended SLO never blocks. The gate reports it under advisories so you can still see that nothing is watching that service. Any member can do this, and Resume reverses it.
3

Opt the SLO out

Edit the SLO and set Gate deploys on this SLO to Never gate deploys. This is permanent until you change it back.
4

Override for a limited time

For a one-off emergency, grant a time-limited override (see below).

​
Override the gate for a limited time

An override lets deploys through despite every reason the gate is holding for: budget, burn rate, an untrusted measurement, an active incident or a freeze. The reasons are not erased. They are reported under advisories next to the allowed answer. Every override is attributed to the person or key that set it, written to the audit log, and expires on its own after at most 72 hours. Over the API, with a key that has the api:write scope:
duration_hours defaults to 4 and is limited to 1 through 72. The response confirms the service and the expiry time. In the app, an organization admin can do the same from Settings on the Deploy Policies tab: click Override on the service’s policy, choose how long (1, 4, 8, 24, 48 or 72 hours), enter a Reason and click Override the gate. The policy must be enabled. Clear ends an override early.

​
Set thresholds and freezes

Admins manage per-service policies under Settings on the Deploy Policies tab. Click Add Policy and set: Click Freeze on a policy to stop deploys of that service for 1 hour up to 30 days. Give a Reason, which the gate quotes back to anyone it blocks, and click Freeze deploys. Clear lifts it early.