CI/CD release gate
Verification in the release path — when you're ready for it
Most customers start with nightly and post-deploy coverage we run for them. When your team is ready to put verification directly in the release path, you can trigger a Suite from your pipeline and gate the deploy on the result. This is optional — the managed service stands on its own.
How it works
Your pipeline calls our API with a scoped key to start a Suite (a grouped set of workflow checks). The call returns an Execution id you can poll, then pass or fail the stage on its verdict.
# Trigger a verification Suite as a release gate
curl -X POST https://app.releaseassurance.com/api/suites/$SUITE_ID/run \
-H "Authorization: Bearer $RA_API_KEY" \
-d '{ "environment": "uat", "reason": "release-1.42" }'
# → { "executionId": "exec_…", "status": "queued" }
# Poll the Execution, then gate the deploy on its result.
curl -X POST https://app.releaseassurance.com/api/suites/$SUITE_ID/run \
-H "Authorization: Bearer $RA_API_KEY" \
-d '{ "environment": "uat", "reason": "release-1.42" }'
# → { "executionId": "exec_…", "status": "queued" }
# Poll the Execution, then gate the deploy on its result.
Good fits
- A pre-deploy gate on your UAT sandbox before promoting a release.
- A per-PR smoke check on your most critical flows.
- A pre-demo "is everything green?" run triggered on demand.
Note on consumption. Scheduled and CI runs draw from your Protected UI Minute pool at the normal rate; on-demand "run it now" runs draw at 2×. High-frequency per-PR gating is available as an add-on — see Pricing.