RenderLog guides
Use these guides to decide what to capture, what to monitor and when to add baselines, alerts or longer history. Each article starts from a real page task, not a generic testing checklist.
Start here
Pick the path closest to the page you need to protect or render.
API output
Choose this when a product, backend job or customer task needs screenshots, PDFs, HTML, Markdown or stored files.
Recurring checks
Use this when the same URL, viewport and page state need to be checked again with history and review.
Pricing pages
Start here when plan cards, discounts, checkout links or localized prices can drift after product changes.
Pricing pages change often and fail in ways uptime checks miss. Keep the visible page, the accepted state and the next pricing decision in one review path.
Use this when: Watch the full pricing page, not only one selector or API response.
Use immediate alerts for broken pages and daily digests for stable check history that should not interrupt the whole team.
Use this when: Use every run for urgent checks and broken-page signals.
Use base history for recent review. Add one-year retention when older result files, accepted baselines or audit evidence must stay within reach.
Use this when: Base history focuses on the last 30 days.
Failure rules keep bad captures out of review so teams spend time on real page changes, not pages that loaded the wrong state.
Use this when: Use presets for common failures such as challenge pages, CAPTCHA and login walls.
Start with GET for a quick render. Move to POST when the request needs secrets, longer input, storage routing or repeatable steps.
Use this when: Use GET for a quick URL to screenshot, PDF, HTML or Markdown run.
A screenshot becomes review material when the team can see the accepted state, the new state and who owns the next decision.
Use this when: A baseline marks the state the team has accepted.
Put a page on a schedule when somebody owns the result and the same capture setup has to run again.
Use this when: Release checks after deploys.
Start manually when a page needs a quick visual answer, then save the same setup for automation only if the check repeats.
Use this when: Validate a reported layout issue without waiting for a schedule.
A page capture earns trust when the next person can see the file, setup, accepted state and review decision together.
Use this when: Capture the current page from the dashboard or API when the team needs evidence.