Verified deploys

A successful deployment is not the same as a working app. Verification reports tell you what was checked, what failed, and what to do next.

Deploy, read, fix, re-check

CLI

rivtor deploy
rivtor verify my-app
rivtor verify my-app --json
rivtor status my-app

When the API returns verification, the deploy output ends with its verdict, summary, check counts, issues and report link. The dashboard shows that same report on the deployment and in the project’s Verification tab. A manual re-check checks the current live app; it does not re-run an old deployment or apply a fix.

Verification verdicts
Verdict	Meaning	Next step
`working`	The verifier returned a working verdict for the checks it ran.	Review coverage; skipped checks are not passes.
`partly_working`	Some checks need attention.	Read each cause, location and suggested fix.
`broken`	A blocking check failed.	Fix the cause and deploy again. Check the blocked flag and deployment status before assuming the candidate is live.

A candidate report describes checks before traffic switched; a live report describes the public app at the time of the check. Neither is a permanent uptime guarantee. Missing, skipped and unavailable reports are never shown as working.

Read the evidence

Reports include the groups that ran and the reason for skipped groups, page results when available, and screenshots when captured. Issues include severity, check group, location, cause, source file when known and a suggested fix. An auto-fixable label is not consent: simply viewing or re-running a report changes no configuration.

The six core groups are reachability, pages, API, data, config and security. Coverage depends on the app and the verifier. Standard checks use safe GET and HEAD requests, not form submissions. Inspect the actual coverage rather than assuming every integration was tested.

Private report links

Report links at /r/<id> and screenshots require an authenticated account with access to the project. Sharing the URL does not grant access. Screenshots are fetched through an authenticated same-origin route, not a public image CDN. They can contain app content, so use appropriate test data and keep project membership limited.

Skip verification explicitly

Skip post-deploy verification

rivtor deploy --no-verify

This forwards verify: false through full uploads, incremental blob uploads and cached-manifest deploys. It does not bypass release security checks. --no-wait only stops waiting; it does not disable verification. A dry run is a plan, not a verification report.

API contract

Authenticated REST routes

POST /v1/projects/:slug/verify             # body: {} → VerificationReport
GET  /v1/projects/:slug/reports            # { reports: [...] }, newest 50
GET  /v1/reports/:id                       # VerificationReport
GET  /v1/reports/:id/screenshots/:index    # private PNG

DeployResult.verification contains the report, or verificationSkipped records a skipped run. Project status includes verification with the last verdict, report URL, timestamp and open issue count. Older APIs may omit these fields; the CLI preserves their deploy result and makes the absence explicit.

rivtor verify exits 0 only for working, and 1 for other verdicts or errors. Deploy retains its existing deployment-status exit codes; automation should inspect verification.verdict in --json output separately.

When a check cannot run

If your session expires, sign in again. If access is denied, ask the project owner. A missing report can mean it was removed or that the API does not support verification yet. Retry transient failures without changing app configuration. Existing deployment logs, rollback and rebuild controls remain available.

For structured build errors, see Errors. For deploy commands and all existing flags, see CLI.