Release checks
Save the public pages and browser steps you want to check, then run the same checklist manually for each release.
Open Website projects, then select a website or add and verify one. Your project and run evidence stay private.
Keep the checklist beside the release evidence
From a website project, open Release checks and save one to five public pages on its exact origin. Choose a desktop or mobile viewport and state the HTTP response and visible text you expect.
You can add read-only steps, such as opening a menu and checking the text it reveals. Each page receives two fresh browser samples before the saved steps. Screenshots and the final checks cover the observed page state.
Use a baseline you have reviewed
Start a run with a release label. Inspect the results before approving a baseline. Later runs compare compatible evidence with that baseline and keep unavailable checks separate.
Changing the plan or measurement profile can prevent comparison. A visual difference calls for review; it does not establish that the page is broken.
Worked example: checking a menu after a release
Illustrative summary of a controlled test page. This is not a customer result or a measurement of your website.
Saved checklist
Expect HTTP 200. Click #menu-toggle, then expect #menu-state to contain Menu open. Enable JavaScript and deployment observations to collect related browser evidence.
- Observed in the controlled healthy run
- Both fresh samples returned HTTP 200. The menu click and text expectation passed, and the bounded deployment capture recorded no observed issues. No baseline had been approved, so visual comparison was unavailable.
- If the menu expectation fails
- Review the failed step, current screenshot and browser evidence. A missing menu state may follow a failed script or a changed selector. Check those observations before assigning a cause.
- If a sample or comparison is incomplete
- Keep its unavailable result visible. A missing baseline or incomplete capture cannot establish that an earlier issue is fixed. Inspect the affected coverage and repeat the same plan after addressing the measurement limit.
The healthy fixture also had an audit-policy-blocked request. That restriction remained a measurement limit. Passing the saved menu check did not prove that every part of the page worked.
A manual check of selected public states
Release checks run when you start them. They use a fixed viewport and unthrottled browser measurements from this server. Optional performance budgets are lab limits, not real-visitor measurements.
Checks do not sign in, enter text or submit forms. Write requests, downloads, WebSockets and navigation outside the approved origin are blocked. Automated accessibility findings cover the observed state and do not establish full conformance.
The latest five completed runs are retained for up to 30 days; the approved baseline and active runs are kept. Keep hostname verification in place for each run, and review exported content and screenshots before sharing them.