Re-checks
Run the same approved plan again after a fix, without a new approval.
A re-check runs every journey of an approved plan again, against the live app, after a fix has been deployed. It returns a new verification id and points back at the run it repeats; the earlier record is never touched. It runs all the journeys, not only the failed ones, because a run over a subset can only prove a repair, not the whole claim.
When no new approval is needed
- Within 24 hours of the person's approval of the plan.
- For at most 10 re-checks of that approval.
- On the same site: the same scheme and host. A different path on that site is allowed.
Outside those limits the API answers recheck_window_closed or recheck_limit_reached. Start a new verification and a person approves its plan again.
How to start one
API, CLI and MCP
POST /v1/verifications/vrf_9c1e0f2a41/recheck # optional body: { "deployment_url": "..." }
vraelis recheck vrf_9c1e0f2a41 --wait
vraelis_recheck { "verification_id": "vrf_9c1e0f2a41" }The response carries recheck_of, rechecks_left and recheck_window_ends_at, and GET /v1/verifications/{id} reports recheck_of on every run. A re-check needs a key with launch access, because it spends.