🇺🇦
3 min read

Failure rules for wrong screenshot results

RenderLog can fail a screenshot or visual check when the browser reaches a challenge page, CAPTCHA, login wall, missing selector or another wrong state.

visual checksscreenshot automation
On this page
  1. Bad results should not look like real changes
  2. Where failure rules matter most
  3. Add the first rule set

Use this when

  • Use presets for common failures such as challenge pages, CAPTCHA and login walls.
  • Use selector, text and status rules for product-specific checks.
  • Failed runs without a real result are not billed.
Failure rules for wrong screenshot results

Bad results should not look like real changes

A visual check matters only when it captures the page the team meant to review. Challenge pages, CAPTCHA screens, login walls, missing app roots, empty HTML and missing selectors are different. They are not product regressions. They are failed runs that need a clear status.

RenderLog failure rules are built for that boundary. They let a workspace flag known bad states before the result becomes noise in review history.

Where failure rules matter most

Failure rules matter most on production pages that can load different states depending on geography, authentication, cookies or third-party services. A pricing page might load a consent wall. A dashboard might redirect to sign-in. A marketing page might ship without the expected root element after a CMS edit.

Without explicit rules, those results can look like visual diffs and waste review time. With rules, the run has a clear status, the team knows why it failed and the history stays focused on real page changes.

  • Release checks can fail fast when the expected selector is missing.
  • Client reports can separate broken access from changed design.
  • Automation can alert on the right problem instead of storing a misleading image.

Add the first rule set

Start with the built-in presets, then add one or two rules that prove the browser reached the page you meant to review. For most teams, that means an app root, stable heading, pricing table or checkout element that must exist before review starts.

Keep the rule set small. A good failure rule separates bad access or broken loading from a real visual change. It should not turn every harmless content edit into a failed run.

Related links

API docs

FAQ

Do failure rules replace visual review?
No. They catch clearly wrong results before review, so reviewers spend time on real page changes.
Are failed runs billed?
Failed runs without a real result are not billed. The status still explains why the run failed.