> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sreagent.app/llms.txt
> Use this file to discover all available pages before exploring further.
# Gate deploys on reliability
> Ask SRE Agent whether a service is safe to deploy from your pipeline, understand a blocked answer, and unblock it.
export const Plan = ({tier}) => {tier} plan;
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`:
```bash theme={null}
status=$(curl -s -o gate.json -w "%{http_code}" \
-H "Authorization: Bearer $SRE_AGENT_API_KEY" \
"https://sreagent.app/api/deploy-gate/payments-service")
if [ "$status" != "200" ]; then
echo "Deploy blocked:"
jq -r '.reasons[]' gate.json
exit 1
fi
```
`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
| Status | Meaning |
| - | - |
| `200` | Safe to deploy. `allowed` is `true` and `reasons` is empty. |
| `423 Locked` | Not safe to deploy. `allowed` is `false` and `reasons` names each cause. |
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](/guides/prevent/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:
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.
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.
Edit the SLO and set **Gate deploys on this SLO** to **Never gate deploys**. This is permanent
until you change it back.
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:
```bash theme={null}
curl -s -X POST \
-H "Authorization: Bearer sre_ak_xxxxxxxxxxxx" \
-H "Content-Type: application/json" \
-d '{"reason": "Shipping the fix for the payments outage", "duration_hours": 4}' \
"https://sreagent.app/api/deploy-gate/payments-service/override"
```
`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:
| Field | What it does |
| - | - |
| **Service Name** | The service the policy applies to. |
| **Error Budget Threshold (%)** | Hold deploys below this remaining budget. Set 0 to turn the budget check off. |
| **Block on high burn rate** | When unticked, burn-rate reasons are reported as advisories instead of blocking. |
| **Block on active critical incidents** | When unticked, active incidents are reported as advisories instead of blocking. |
| **Enabled** | A disabled policy is ignored and the defaults apply. |
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.
## Related
* [Monitor endpoints with synthetic checks](/guides/prevent/synthetic-checks): link a check to a service so it gates deploys.
* [Manage people and roles](/guides/administer/organizations-and-roles): who can override a gate.
* [Troubleshooting](/guides/reference/troubleshooting): what to do when the gate is locked.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.