RenderLog guides
Use these guides to decide what to test without code, what to compare visually and when a rendered file should become a recurring check. Each article starts from a real page task, not a generic testing checklist.
Start with a real page, define the expected result and use the matching walkthrough to set up your first run.
Plan the target, schedule and review process before enabling alerts.
Choose visual, form, content or SEO checks for the outcome you need.
Choose a one-off capture or a saved check and keep credentials private.
Start with GET for a simple public page, use POST for structured settings and poll the job when the render runs asynchronously.
Use this when: Use GET for a simple public URL and small set of options.
Monitor the page states that matter to your business, then review a useful diff instead of collecting screenshots nobody owns.
Use this when: Name the page owner before choosing a schedule.
Start with the form state a person already checks, then make its expected text, values and visible result reviewable after every run.
Use this when: Choose a form with a named owner and a real business consequence.
SEO problems and UI regressions often look healthy to uptime checks. Public pages need checks that read the page the way a reviewer and a crawler would.
Use this when: Confirm that indexable pages still return 200 and are not blocked by robots tags.
If a person already checks the page by hand before release, that page is a strong candidate for a no-code web test.
Use this when: Pricing page: the plan price and call to action still look right.
Pricing pages usually break in ways uptime checks miss: a wrong CTA, a shifted mobile table, a stale discount, or the wrong plan.
Use this when: Wrong call to action after a campaign update.
Not every passed or failed run deserves an interruption. Some teams need a decision inbox, not a constant stream of pings.
Use this when: Immediate alerts for urgent failures and blocked states.
Retention is a product decision, not just a storage setting. Keep short history fast and pay for longer evidence only when it matters.
Use this when: Recent history for current QA and launch review.
A broken page should not quietly become a new baseline or a fake pass.
Use this when: Login wall instead of the expected page.
Choose GET for a fast one-off call. Switch to POST when the run needs real setup, structured checks, or ownership.
Use this when: GET: fast call with a URL and a few query parameters.
Turn the next important page into a saved result, a reviewed baseline or a recurring check instead of leaving it as a one-off issue.