Short answer. An uptime check in CI/CD is a post-deploy smoke test: the pipeline hits the new release's health endpoint, waits for a 200 status and the expected marker in the body, and only then treats the deploy as successful. On failure it triggers an automatic rollback. This catches the "green deploy, dead site" class of bugs before users see them. But a CI check is one-shot — afterward an external synthetic monitor watches continuous uptime.
Why check availability in the pipeline
The most dangerous incident class is when the pipeline is green, the artifact built, pods came up — but the app does not respond: a migration failed, a secret was not picked up, a config broke. Without a post-deploy check you learn about it from users.
- Smoke test — a minimal "app is alive" check right after release;
- Health gate — deploy succeeds only on a 200 from health;
- Auto-rollback — a failed check rolls the release back;
- Post-deploy monitoring — an external checker watches afterward.
Curl check in GitHub Actions
A basic smoke-test step with retry: wait for the new release to warm up and verify the response code.
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Deploy
run: ./deploy.sh
- name: Smoke test health endpoint
run: |
set -euo pipefail
URL="https://example.com/healthz"
for i in $(seq 1 10); do
code=$(curl -sS -o /tmp/body.txt -w "%{http_code}" --max-time 5 "$URL" || echo "000")
if [ "$code" = "200" ] && grep -q '"status":"ok"' /tmp/body.txt; then
echo "Health OK on attempt $i"
exit 0
fi
echo "Attempt $i: HTTP $code, retrying in 6s..."
sleep 6
done
echo "Health check failed after 10 attempts"
exit 1
- name: Rollback on failure
if: failure()
run: ./rollback.shWhat to verify in a smoke test
| Check | Why | Failure signal |
|---|---|---|
| HTTP 200 on /healthz | App responds | 5xx or timeout |
| Marker in response body | The real app answers, not a stub | Expected string missing |
| Version in /version | The right build is deployed | Old commit hash |
| Dependency readiness | DB and cache reachable | readiness != ready |
A smoke test must be fast and deterministic. One or two requests with retry, not a full e2e run. The goal is to catch a catastrophe in seconds, not to test the whole product.
Retry logic and timeouts
A new pod does not respond instantly — it needs to warm up. So the smoke test should make several attempts with a pause and an overall deadline. Without retry the check fails on the very first request to a not-yet-ready release and triggers a false rollback.
After the pipeline — external monitoring
A CI check is one-shot: it confirms the deploy but does not watch the site afterward. A certificate will expire in a month, a third-party API документацию will go down at night, DNS will drift — the pipeline never learns about it.
enterno.io takes the baton as continuous synthetic monitoring: HTTP / SSL / Ping / DNS from RU / EU / US regions, free tier with 10 monitors at a 5-minute interval (paid — 1 minute / 30 seconds). Through the REST API v4 you can create or enable a monitor for the new endpoint straight from the pipeline. And the MCP server (16 tools for Claude, Cursor, Zed) lets an agent run availability checks from the IDE.
FAQ
How is a smoke test different from e2e?
A smoke test verifies the app is alive at all (1–2 requests). E2E runs full user scenarios. After a deploy you want a fast smoke check; run e2e as a separate stage.
How do I implement auto-rollback on a health check?
In GitHub Actions use if: failure() on the rollback step. When the smoke test fails the job is marked failed and the rollback script runs.
How many retries should a smoke test do?
Usually 5–10 attempts with a 5–6 second pause and an overall deadline of about a minute — enough for the release to warm up without dragging out the pipeline.
Can I manage monitors from the pipeline?
Yes, through the enterno.io API v4: create a monitor for a new endpoint or enable an existing one with a single POST request from CI.
Connect deploy with monitoring: set up a monitor at enterno.io/monitors and drive it through the API from your pipeline. Next: health-check endpoints, monitoring as code, alerting best practices.