TinyCheck · Practical guide · Reviewed September 8, 2026
Add a browser smoke check after your next deployment
Check a specific heading on an owned deployed page, recover a run after a lost response, and distinguish queued work from a verified result.
A successful deployment tells you that your release process completed. A small browser check answers a separate question: does the published page contain the heading you intended to ship?
TinyCheck by TinyScale supports an agent-friendly path for that check on a public HTTPS page you own. Start with one stable heading on a page such as your app's public getting-started screen. This catches a missing or unexpected page element; it does not establish that login, payment, or every user journey works.
How do I check a page after deployment?
Create a TinyCheck assertion for an expected heading on an owned HTTPS page. After deployment, start a run with a stable key for that intended check and wait for its terminal result. A queued run is not a passing test; inspect verified=true.
Prefer your agent to handle setup? Use the TinyCheck setup prompt, then return here for the details.
Establish the check once
Follow the setup walkthrough to create a bounded preview and publish the origin-ownership challenge. Use the same project directory for every command.
After ownership confirmation, create your assertion:
npx -y tinyscale@0.10.0 check create --origin-id ORIGIN_ID --url https://owned-project.example/getting-started --heading "Getting started"
Replace the origin ID, URL, and heading. The CLI checks the exact heading text. Use an assertion that reflects what should be on the page, rather than text whose wording changes on every release.
Give each intended run a stable identity
Once the page is deployed, run the returned suite:
npx -y tinyscale@0.10.0 check run --suite SUITE_ID --idempotency-key release-smoke-0001
npx -y tinyscale@0.10.0 check status --run RUN_ID
Replace the suite and run IDs with actual results. Browser execution is asynchronous. Follow the status until terminal; verified=true is the passing result for this CLI flow. A run ID means the work has an identity, not that the page passed.
If a transport failure hides the response to check run, retry the command with the same suite and release-smoke-0001 key. That recovers the original operation. When intentionally checking a later deployment, use a different stable key, such as release-smoke-0002. Reusing the old key is not a way to request a fresh browser visit.
Interpret what happened
If the assertion fails, first confirm that you are checking the intended URL and exact heading. If the run reports a platform problem, keep that separate from a product regression. An unavailable check does not prove that your app is unavailable.
A heading match can also pass while another part of the page is broken. This is a narrow smoke check that complements your existing tests. It does not compare a commit hash, prove freshness of every cached asset, or exercise form submission.
The preview path allows one flow and a maximum duration of 30 seconds. It does not type into forms or perform arbitrary clicks. Use an owned public preview when developing locally; do not expose private data just to make a test reachable.
Make the handoff useful
Share the tested URL, expected heading, run identity, and terminal result with the person reviewing the release. After the preview is proven, workspace claim opens the human claim flow without printing its private link. Claim preserves the integration under hard Free limits without buying a plan.
This walkthrough is a manual post-deploy step. It does not install a CI integration, schedule checks, or change deployment policy. Keep credentials in private CLI state and make those broader integrations explicit if you choose to add them.
Use the full setup guide for origin verification and the current reference for supported commands.
Common questions
Should every retry use a new run key?
No. Reuse the same key after a lost response to recover the intended run. Use a new stable key for a deliberately new check, such as a later deployment.
Is this a complete CI or checkout test?
This guide is a manual post-deploy heading check. It does not install CI automation or exercise login, payment, form submission or arbitrary clicks. A service failure is also distinct from an assertion failure.