3 open incidents
Order Worker — SLO “Order Processing Success Rate” is RED Checkout API — SLO “Checkout Latency” is RED Payments API — SLO “Payments Availability” is RED
View details
{# ------------------------------------------------------------------- HERO COCKPIT – only shows if the view passes a "decision" object. -------------------------------------------------------------------- #}

Safe to Deploy – Payments API prod Red

Real-time risk cockpit combining SLOs, incidents and recent deployments.

0/100
⛔ Blocked
⛔ Blocked – here's what must be fixed
Deployment is blocked because a required dependency is unhealthy: Checkout API. Investigate the dependency before deploying Payments API.
  • SLO 'Payments Availability' is red. SLI=0.900, target=99.900. Error budget remaining ~0.000. Burn rate ~1.00x.
  • There are open incidents, highest severity = critical.
  • Dependency 'Checkout API' is unhealthy (SLO=red, incident severity=critical).
AI reasoning:
For service 'Payments API' in environment 'prod', the current deployment risk score is approximately 0/100 with overall SLO health 'red'. Key SLO signals: error budget remaining ~0.000, burn rate ~1.00x. Incident posture: 1 open incident(s), highest severity critical. Based on these signals, DeployGuard classifies this deployment as 'red' and recommends following the suggested status ('blocked').
SLO Status
Payments Availability · Last 30 days

Target: n/a

Current: 0.9%

Error budget remaining: 0%

Burn rate: 1.00x

Recent Deployments
  • v2.4.1 · Aug. 18, 2026, 8:50 a.m. Green 14/100
  • auto-slo-refresh · Aug. 18, 2026, 8:50 a.m. Red 1/100
Incidents & Change Freeze
Open incidents
  • #418 critical Payments API – Payments Availability SLO is RED · open
Change freeze

No active change freeze window.

{# ------------------------------------------------------------------- ORIGINAL API DOCS -------------------------------------------------------------------- #}

Safe to Deploy API

CI/CD pipelines use this endpoint to automatically check whether a service is safe to deploy based on real-time SLO health and burn-rate calculations. This API is protected using organisation-scoped tokens.

API Endpoint
POST /api/safe-to-deploy/
GET  /api/safe-to-deploy/?service=NAME&env=prod
    
Required Headers
X-API-TOKEN: <your token>
Content-Type: application/json  (for POST)
    

Request Format

Sample JSON Body (POST)

{
  "service_name": "Network",
  "env": "prod"
}

Example — Curl

Replace YOUR_TOKEN_HERE with your generated API token.

curl -sS \
  -H "X-API-TOKEN: YOUR_TOKEN_HERE" \
  -H "Content-Type: application/json" \
  -X POST "https://sre.sydatrix.com/api/safe-to-deploy/" \
  -d '{
    "service_name": "Network",
    "env": "prod"
  }'

CI Example — GitHub Actions

Save your token in Settings → Secrets → Actions as SAFE_TO_DEPLOY_TOKEN.


- name: Check Safe to Deploy
  env:
    SAFE_TO_DEPLOY_TOKEN: $
  run: |
    set -e
    BASE_URL="https://sre.sydatrix.com"
    SERVICE="Network"
    ENV="prod"

    RESPONSE=$(curl -sS \
      -H "X-API-TOKEN: ${SAFE_TO_DEPLOY_TOKEN}" \
      -H "Content-Type: application/json" \
      -X POST "${BASE_URL}/api/safe-to-deploy/" \
      -d "{\"service_name\": \"${SERVICE}\", \"env\": \"${ENV}\"}"
    )

    echo "$RESPONSE"

    SAFE=$(echo "$RESPONSE" | jq -r '.safe')
    if [ "$SAFE" != "true" ]; then
      echo "❌ Not safe to deploy: $(echo "$RESPONSE" | jq -r '.reason')"
      exit 1
    fi

    echo "✅ Safe to deploy"

CI Example — Jenkins Pipeline

Store the token as a Secret Text named safe_to_deploy_token.


stage('Safe to Deploy') {
  steps {
    withCredentials([string(credentialsId: 'safe_to_deploy_token', variable: 'SAFE_TO_DEPLOY_TOKEN')]) {
      script {
        def baseUrl = 'https://sre.sydatrix.com'
        def service = 'Network'
        def env = 'prod'

        def payload = """{
          "service_name": "${service}",
          "env": "${env}"
        }"""

        def response = sh(
          script: """
            curl -sS \
              -H "X-API-TOKEN: ${SAFE_TO_DEPLOY_TOKEN}" \
              -H "Content-Type: application/json" \
              -X POST '${baseUrl}/api/safe-to-deploy/' \
              -d '${payload}'
          """,
          returnStdout: true
        ).trim()

        echo "Safe-to-deploy response: ${response}"

        def safe = sh(
          script: "echo '${response}' | jq -r .safe",
          returnStdout: true
        ).trim()

        if (safe != 'true') {
          def reason = sh(
            script: "echo '${response}' | jq -r .reason",
            returnStdout: true
          ).trim()
          error "❌ Not safe to deploy: ${reason}"
        }

        echo "✅ Safe to deploy"
      }
    }
  }
}

Legacy Single-Token Mode

If deploying self-hosted and not multi-tenant, your platform may optionally use a single global API token stored as an environment variable:

export SAFE_TO_DEPLOY_API_TOKEN="YOUR-GLOBAL-TOKEN"

CI/CD pipelines still send it like:

X-API-TOKEN: YOUR-GLOBAL-TOKEN
Recommended: Use the UI-managed tokens for multi-company or SaaS setups. They allow naming, revoking, expiring, rotating, and tracking per pipeline.

{# ------------------------------------------------------------------- MULTI – Feature grid for business value (clickable, coloured tiles) -------------------------------------------------------------------- #}

Multi-signal Safe-to-Deploy brain

The decision combines technical telemetry with business and customer context. These are the levers you can wire up: