Give your coding agent a verified deployed-page check

“The build passed” leaves an important question unanswered: does the deployed page show the thing you expected? TinyCheck by TinyScale runs a browser check against an authorized public HTTPS page and gives the agent a result it can inspect.

Start with one precise assertion: your deployed page contains a heading with the exact text “My project.” This is a useful smoke check, not proof that every user journey works.

How can a coding agent verify a deployed page?

With TinyCheck, verify ownership of an HTTPS origin, create a check for an exact heading, then run it and poll until the result is terminal. Only verified=true establishes a passing check. This verifies the selected page assertion, not an entire application.

Prefer your agent to handle setup? Use the TinyCheck setup prompt, then return here for the details.

Prepare an owned page and preview

You need Node.js 20 or later and an HTTPS page you are authorized to test. Local-only pages cannot be reached by the remote browser; publish an owned preview first.

From your project directory, run:

npx -y tinyscale@0.10.0 workspace create --name "Deployed page example" --cohort external
npx -y tinyscale@0.10.0 workspace status

The preview lasts 72 hours and needs no account or card. Keep the CLI's private .tinyscale state out of source control and agent context. Run subsequent commands from this same directory.

Prove origin ownership

Replace the example origin with your own:

npx -y tinyscale@0.10.0 check origin --origin https://owned-project.example

Publish the returned challenge at the exact well-known path specified by the response. Then use the returned origin ID:

npx -y tinyscale@0.10.0 check confirm --origin-id ORIGIN_ID

Do not substitute a third-party website or attempt to bypass a login, CAPTCHA, or bot control. Origin verification and navigation checks are part of the test boundary.

Run a specific assertion

Replace the origin ID, URL, and heading with your actual values:

npx -y tinyscale@0.10.0 check create --origin-id ORIGIN_ID --url https://owned-project.example --heading "My project"
npx -y tinyscale@0.10.0 check run --suite SUITE_ID --idempotency-key first-check-0001
npx -y tinyscale@0.10.0 check status --run RUN_ID

Use the suite and run IDs returned by the previous commands. Poll status until the run reaches a terminal state. Only verified=true establishes the passing result for this flow; accepting a run is not the same as completing it.

If the run request loses its response, repeat it with the same idempotency key to recover the original run. For a deliberately new check, use a new stable key. A failing heading assertion should lead to inspecting the page or expectation, not relabeling the run as success.

Make the handoff concrete

Show the owner the completed result, the tested page, and what the assertion covered. Then run:

npx -y tinyscale@0.10.0 workspace claim

The human claims the project in their browser on Free, preserving IDs and narrow agent access without buying a plan.

Preview checks allow one flow with a maximum 30-second duration. They do not submit forms, type into fields, or perform arbitrary clicks. This example does not exercise authenticated sessions, purchases, or a full checkout. Expand your verification strategy around the actual risks in your app, while keeping TinyCheck failures separate from your application's availability.

See the current integration guide for supported commands and boundaries.

Common questions

Can TinyCheck reach localhost?

The remote browser cannot reach a local-only development page. Use an owned, published HTTPS preview without exposing private data.

Does a passing heading check prove a deployment is correct?

It proves the selected assertion passed on the tested page. It does not prove authenticated checkout, asset freshness or every user journey. See a post-deploy smoke check for retry identities and result interpretation.