Run a smoke test on a deploy in about a minute

Breadth over depth. A smoke test touches many things shallowly to prove nothing is catastrophically broken. If it takes longer than a couple of minutes, it has stopped being a smoke test and become a regression suite.

• The page renders at all, and the primary call to action is present.
• Main navigation goes where it says it goes.
• Nothing 404s or redirects somewhere unexpected.
• The console is clean, and no request came back 4xx or 5xx.

Open the page, verify it renders correctly, click through the main navigation, and report broken links, layout problems, console errors and failed network requests.

Two narrower variants worth keeping around:

Collect every link in the main navigation and footer with computer.elements(), open each one, and report any that 404, redirect somewhere unexpected, or come back with console errors. Come back to the start page between links.

Load the page, wait for it to settle, scroll to the bottom and back. Then report everything computer.diagnostics() found: console errors, uncaught page errors and failed or 4xx/5xx requests, with the URL of each failing request.

• Pass — every named check was answered and passed.
• Fail — a check was answered and did not pass.
• Blocked — the run could not reach a state where the check was answerable: a login wall, a geo-block, a bot challenge. That is information, not a failure, and it is reported separately so it does not pollute your pass rate.

A page that renders perfectly while the console fills with exceptions and /api/profile quietly returns 404. Every run collects console errors, uncaught page errors and failed responses whether or not the prompt asked for them, so this surfaces as a finding rather than as a mystery three weeks later.

• Model — a fast model (Claude Haiku 4.5, GPT-5.6 Luna) is fine for a flow you run often. Reach for a deeper model when a run keeps getting stuck on the same step.
• Devices — laptop is enough for a first pass. Add phone when the flow is mostly used on mobile.
• Step budget — 30 scripts covers most flows. Raise it for long, multi-page journeys.
• Reasoning effort — passed straight through to the model. Higher effort costs more and thinks longer before acting.

• A verdict: pass, fail or blocked.
• Named checks, each marked passed or not, so you can see what was actually asserted.
• Findings rated critical, high, medium, low or info, with the evidence behind each one.
• A screenshot for every step, plus a session video on Pro and Team when you turn recording on.
• Console errors, uncaught page errors and failed or 4xx/5xx requests, collected automatically.
• Passive security findings from the responses the run loaded: headers, cookies, mixed content, open redirects, source maps, leaked secrets and stack traces.

Worth knowing before you point it at something important.

• Schedules run at most once an hour, on Pro and Team. This is not minute-level uptime monitoring.
• No CLI. A run starts from the app, a schedule, or a pull request through the GitHub App.
• Alerts are email only. For paging or a status page, use a monitoring tool alongside this.