Skip to content
Concepts · 8 min read

How Deploy Gate
Scoring Works

Deploy Gate evaluates five independent signals and combines them into a single deploy decision: GO, CAUTION, or HOLD. Here's exactly how it works.

01

The 5 Signals

Active Incidents

PagerDuty

Checks whether any open incidents are currently firing for this service or its dependencies. A live incident means something is already broken — deploying on top of it adds blast radius and makes root cause analysis harder.

CRITAny P1 or P2 incident open
WARNAny P3 incident open, or a recent incident resolved < 30 min ago
OKNo open incidents

Change Velocity

GitHub Actions

Measures deploy frequency and recent failure rate from your CI/CD pipeline. High deploy frequency with recent failures is a warning sign — the pipeline is unstable and the next deploy may fail too.

CRITDeploy failure rate > 30% in the last 24h
WARNDeploy failure rate 10–30%, or > 5 deploys in 1h (unusually high churn)
OKFailure rate < 10%, normal deploy cadence

SLO Budget

Coming soon

Tracks your error budget consumption rate. When you're burning error budget fast, a deploy that causes even a small degradation can exhaust the remaining budget and trigger an SLO breach.

CRITError budget exhausted or burning at > 5× normal rate
WARNBurn rate 2–5× normal
OKBurn rate normal, healthy budget remaining

System Health

Coming soon

Evaluates infrastructure-level health signals — CPU, memory, latency, error rates — from your observability stack. Deploying into a system already under stress is higher risk.

CRITKey health metrics outside normal bounds (p99 latency spike, error rate elevated)
WARNMetrics trending toward bounds but not yet critical
OKAll metrics within normal operating range

Dependency Changes

GitHub Actions

Detects whether upstream services this service depends on have been recently deployed. Cascading changes across services without coordination is a common cause of incidents.

CRITA critical upstream dependency deployed in the last 15 min
WARNAny upstream dependency deployed in the last hour
OKNo recent upstream changes
02

How Signals Combine

The combination logic is intentionally simple and deterministic — no weighted scoring, no ML black box. You should be able to reason about why you're getting a HOLD.

HOLD

Any signal is CRITICAL. One CRITICAL is enough to halt the deploy. The gate exists precisely to catch these moments — deploying into a live incident, pushing into an exhausted error budget, or compounding cascading failures.

CAUTION

Any signal is WARNING, none are CRITICAL. Proceed with awareness. CAUTION means conditions are suboptimal but not immediately dangerous. Your team should acknowledge the risk before deploying.

GO

All evaluated signals are OK. Conditions are favorable. Note that signals with no connected integration are not counted — see “Not Evaluated” below.

03

Confidence Levels

A GO verdict means more with more signals. Strake shows a confidence level alongside the deploy decision to help you understand how much of the picture it can actually see.

Level
Meaning
HIGH
3 or more signals evaluated. Strake has a broad view of system state. Trust this verdict.
MEDIUM
2 signals evaluated. Reasonable confidence, but some blind spots exist.
LOW
1 signal evaluated. Limited visibility — connect more integrations to improve accuracy.
04

What “Not Evaluated” Means

A signal shows Not Evaluated when no integration is connected that provides data for that signal.

Not Evaluated signals are excluded from the deploy decision — they neither help nor hurt your score. A gate with two connected integrations giving OK results will show GO (MEDIUM confidence), not HOLD.

Connect more integrations to move signals from Not Evaluated to active. The signals currently requiring connected integrations are: Active Incidents (PagerDuty), Change Velocity (GitHub Actions). SLO Budget, System Health, and Dependency Changes are coming in future releases.

05

Configuring Thresholds

Coming soon

Custom thresholds per service are on the roadmap. Today, thresholds are fixed at the values described in the signal table above. If you have specific thresholds that matter for your team, email rob@strake.dev — these requests are directly shaping the feature.