TinyCheck · Practical guide · September 7, 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.
Establish the check once
Follow the setup walkthrough to download and checksum-verify the CLI, create a bounded preview, and publish the origin-ownership challenge. Use the same project directory for every command.
After ownership confirmation, create your assertion:
bun ./tinyscale-agent-v0.2.0.mjs 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:
bun ./tinyscale-agent-v0.2.0.mjs check run --suite SUITE_ID --idempotency-key release-smoke-0001
bun ./tinyscale-agent-v0.2.0.mjs 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.