# Re-checks

> **Historical. This product is retired.** This page describes the earlier browser-testing product and is kept only as history. Its service, API, console and accounts are closed: do not run the install commands or call the endpoints shown here.

Run the same approved plan again after a fix, within its limits, without a new approval.

- **Outcome:** You can prove a fix on the live app without asking for approval again.
- **Does not do:** A re-check runs the plan that was approved. To check something new, start a new verification.

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

> **Removed.** This example called the earlier service, which is retired. Its commands and endpoints are no longer shown.

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.

> **Billing.** Each re-check is billed as one verification, the same as the first run.

---

Vraelis documentation, Earlier references. https://docs.vraelis.com/recheck