Deployment stages promote a build through environments (e.g. dev → staging → production), and post-deploy smoke tests are a small set of critical-path checks run against each environment immediately after deployment to confirm the deployed system is actually working before proceeding or declaring success.
Passing tests in CI proves the code is good; it does not prove the deployment succeeded. Config drift, a bad environment variable, a failed migration, a broken dependency or a misrouted load balancer can produce a green build that deploys to a broken site. Post-deploy smoke tests close this gap: after each environment deploy, run a handful of fast, high-value checks against the real, running environment — can users load the homepage, log in, and complete one core transaction. These run against the live URL (not a test build), so they validate the deployment and its configuration, not just the code. In a promotion pipeline, smoke tests on staging gate promotion to production, and smoke tests on production (often read-only or synthetic) confirm the release before you consider it done — and can trigger an automatic rollback if they fail.
A release passes all CI tests but a wrong production environment variable points the app at the staging API. Post-deploy smoke tests against the production URL immediately fail on 'log in and load dashboard', the pipeline halts promotion and alerts the team, and the bad release is rolled back before most users notice.
jobs:
deploy-staging:
runs-on: ubuntu-latest
steps:
- run: ./deploy.sh staging
smoke-staging:
needs: deploy-staging
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npx playwright test --grep @smoke
env: { BASE_URL: 'https://staging.example.com' } # hit the REAL deployed env
deploy-prod:
needs: smoke-staging # promote only if staging smoke passed
runs-on: ubuntu-latest
environment: production # can require manual approval
steps:
- run: ./deploy.sh productionScenario: Your CI is fully green, deploys succeed, but twice this quarter production broke immediately after a deploy — once from a bad env var, once from a failed DB migration — and users reported it before the team knew. How do you catch these in the pipeline?