How to Run a Smoke Test After Deploy Then Promote From CI/CD

A post-deploy smoke test exercises the critical path so you promote only a build that actually works.

Deploy to a staging slot or the idle color, run a short smoke test that hits the most important user flows, and promote only if every check passes. A failed smoke test blocks promotion and triggers rollback.

How it works

A smoke test is a small set of real requests against the freshly deployed version: log in, load the homepage, hit one write path. It is faster and narrower than the full suite; its job is to catch a broken deploy before real traffic sees it.

Deploy, smoke test, promote or roll back

deploy-staging:
  runs-on: ubuntu-latest
  steps:
    - run: ./deploy.sh --slot staging --image myapp:${{ github.sha }}
    - name: Smoke test the critical path
      run: |
        set -e
        curl -fsS https://staging.example.com/healthz
        curl -fsS -o /dev/null -w "%{http_code}" https://staging.example.com/ | grep -q 200
        curl -fsS https://staging.example.com/api/status | jq -e '.ok == true'
    - name: Promote to production
      run: ./promote.sh --from staging --to production
    - name: Roll back if anything above failed
      if: failure()
      run: ./deploy.sh --slot staging --rollback

Keep smoke tests fast and stable

Smoke tests must be deterministic; a flaky smoke test blocks good deploys and erodes trust. Cover only the highest-value flows, and reserve the deep end-to-end suite for the pre-merge stage.

Related guides