Choose the smallest API workflow

A screenshot API can serve several different jobs. You may need one image for a report, a configured render with headers and cookies or a repeatable visual check with a baseline and review history. Decide which result you need before choosing the request shape.

The website screenshot API gives RenderLog three practical paths. Use GET for a quick URL-based capture. Use POST when the request needs structured settings. Run a saved check when the page needs an approved expectation and a history that somebody will review.

• Use GET for a simple public URL and small set of options.
• Use POST for headers, cookies, flow steps and failure rules.
• Use a saved check for a baseline, comparison and review history.
• Keep the API token in the calling system's secret store.

Create a token and send it safely

Create a workspace API token with the scope required by the endpoint and keep the returned secret private. Send it in the Authorization: Bearer rl_live_xxx header. RenderLog checks the token, its expiry and its scopes before it starts the run. A token can be revoked or given an expiry in workspace settings.

Do not put a token in a page URL or browser-side code. GET query values can be recorded by logs, browser history or analytics, so keep sensitive headers and cookies in a POST body. The API documentation lists the endpoint authentication and the fields available for each request.

• Use a workspace token rather than a user session for API calls.
• Grant runs:write to start a render and runs:read to poll its job or read the result.
• Send secrets in headers or POST fields that the endpoint supports.
• Rotate or revoke a token when the calling system changes.

Use GET for a simple capture

For a public page with no special setup, call /api/render with a URL and optional rendering parameters. The request can include format, width, height, dpr, selector and fullPage. For example, a URL-encoded page can be captured with format=png and a stable desktop viewport.

The response is a public job shape with an id, a status and a result when the run has completed. The result includes the run and artifact information. Use GET when the URL and options are safe to place in a query string and the request does not need structured JSON.

• Encode the target URL before placing it in the query string.
• Use selector for one element or fullPage=true for the whole page.
• Keep width, height and device scale factor stable for comparisons.
• Read the returned job status before assuming an artifact is ready.

Use POST for real render settings

Use POST /api/render with a JSON body when the capture needs headers, cookies, a user agent, a locale, flow steps, hidden selectors or failure rules. The body accepts a URL for page input and defaults the output format to PNG. It can also render HTML or Markdown input when the request supplies the corresponding body. An ad-hoc render uses RenderLog artifact storage by default; retrieve the artifact URL returned with the job instead of adding a storage setting to the request.

A practical POST body can include url, format, headers and failureRules. Failure rules can mark a result bad when a known challenge appears or when a required selector is missing. That keeps a technically completed browser session from being mistaken for a useful page result.

• Use JSON for settings that should stay readable and reviewable.
• Use headers and cookies only for the target state you are allowed to access.
• Add a missing-selector rule for a required application root.
• Use async: true when the caller should start the job and poll later.

Poll the job and read the artifact

A render can be queued or running before the browser result is available. Poll GET /api/jobs/{id} with the same bearer token until the status reaches a terminal state. The documented statuses are queued, running, passed, failed and canceled. Read the result rows and artifact URLs only after the job has completed.

Keep the job id with the build, report or record that requested it. The returned artifact URL is the evidence that another system can retrieve. If the job fails, preserve the status and result details for diagnosis instead of retrying blindly. A retry may create another billable run and can hide the original setup problem.

• Poll with a bounded interval and stop on a terminal status.
• Treat failed and canceled as outcomes that need handling.
• Store the job and run identifiers beside the calling build or report.
• Retrieve artifacts from the returned URL after the run is ready.

Diagnose failures and choose the next layer

A 401 usually means the bearer token is absent, expired or invalid. A 403 can mean the token lacks runs:write for starting or runs:read for polling, or is trying to access another workspace. A successful request with a failed run points to the page state, access setup, challenge detection or a missing target. Check the run result and the request settings before changing the URL.

The render endpoint creates page evidence. If the page needs an approved baseline, repeated scenarios, assertions or visual review, move to a saved web test and use the API to start its run. If the job is only a one-off image, keep the workflow small. GET and POST API examples can help decide when that boundary has been reached.

Related links

• Website screenshot API
• API documentation
• GET and POST API examples
• RenderLog guides

Choose a change that deserves monitoring

A website change monitor is useful when it answers a real question. Did the pricing page keep its plan table? Is the signup form still visible? Did a content release remove the heading that a campaign depends on? Start with one public URL and one expected state that already has an owner.

Website change monitoring works best for pages where a quiet change has a cost: pricing, signup, checkout, documentation, localized landing pages and client deliverables. Avoid monitoring every URL just because it is possible. A small list with a clear review habit produces better decisions than a large list of unread results.

• Name the page owner before choosing a schedule.
• Record the business reason for watching the page.
• Begin with one state that a person can describe clearly.
• Keep one-off investigations as manual captures until they repeat.

Make every capture repeatable

A diff is only useful when the inputs stay comparable. Keep the URL, viewport, device scale factor, target selector and full-page choice with the check. If the page needs a cookie, request header, wait or flow step before it reaches the expected state, save that setup as part of the same recipe.

Use a selector when the component is the unit of review. Use a full-page capture when the risk is a missing section or a shifted layout. A stable viewport makes the comparison easier to read, while a deliberate wait helps pages that render data after the first response. Do not add delays by guesswork; add them when the page evidence shows that the state is not ready.

• Keep viewport and target settings consistent between runs.
• Use headers or cookies for an access state that the page really needs.
• Prefer the narrowest selector that represents the business risk.
• Save interaction steps only when the page needs them before capture.

Set a cadence that matches the risk

The right schedule follows the decision that comes after a result. A pricing page may need an after-deploy check. A high-traffic landing page may need a daily run. A client site may only need a weekly capture before a report. The cadence should create a review item at the moment someone can still do something useful.

Start with a manual run while you learn whether the expected state is stable. Once the same page and setup repeat, move it into a scheduled check and keep the owner visible. Use an urgent notification only when the changed page needs same-day action. For routine pages, review run history on a regular cadence instead of adding more notifications.

The existing scheduling guide explains the same rule from the automation side: schedule a page when the review already repeats and someone will react.

Review the diff with the page context

When a run changes, first look at the evidence and then decide whether the page changed on purpose. A visual diff can show a missing block, a moved button, a changed font or a responsive layout issue. A text assertion can make a critical value explicit, such as a plan name, price or success message.

Keep the visual baseline and important assertions together when both matter. Approve a new baseline only after checking the page change against the release or content request. If the new state is intentional, promote the expected result from the run so the next comparison starts from a reviewed state. Review diffs and baselines covers that review loop in more detail.

• Read the changed region before accepting a new baseline.
• Use text assertions for values that a screenshot may make hard to judge.
• Record why an intentional change became the new expectation.
• Keep review history attached to the run that produced the evidence.

Diagnose noisy or failed results

A noisy monitor usually points to an unstable input. Check whether a timestamp, rotating promotion, personalized cookie or late-loading element is inside the captured region. Compare the selector and viewport with the last good run. If the page did not reach the intended state, inspect the run failure reason before changing the baseline.

A failed capture can also mean that the page is protected by a challenge or that the selected element disappeared. Use failure rules for known bad states so a technically completed browser run is still marked as a result that needs attention. Tighten the target or wait only after the evidence identifies the source of the noise.

• Check dynamic text and personalized state first.
• Treat a missing selector as a setup problem until proven otherwise.
• Use failure rules for known challenge or missing-content states.
• Do not accept a noisy result as a baseline just to clear the queue.

Know what a visual monitor cannot tell you

A website change monitor tells you what the configured browser state returned and gives a reviewer evidence to inspect. It does not replace analytics, search reporting, accessibility review, application logs or a deep code-based test suite. A page can look unchanged while an API response, permission rule or conversion event is broken.

Use the monitor for the visible, repeatable layer that a team needs to review over time. Pair it with the system that owns the deeper signal. If you cannot name the expected state, the owner or the action after failure, keep the capture manual until those pieces are clear.

Related links

• Website change monitoring
• Schedule screenshot automations
• Review diffs, baselines and alerts
• RenderLog guides

Start with one form state

A form test becomes useful when it checks a state that matters to someone. Pick one public or shared flow: a newsletter signup, a contact form, a trial request or a support form. Write down what a reviewer should see before submission and what should appear after a valid submission.

No-code website testing is a good fit when a product, marketing or support owner needs a readable result but does not want to maintain selectors in a repository. Begin with one path and one outcome. Broadly promising to test every validation branch makes the first check difficult to understand and difficult to keep current.

• Choose a form with a named owner and a real business consequence.
• Describe the expected state before and after the submit action.
• Start with the happy path plus one important validation state.
• Keep test data separate from real customer information.

Prepare a stable page state

Open the page in the state a real reviewer uses. If a cookie, request header or authenticated setup is required, keep that context with the saved check. Add a wait when the form is rendered after a clear loading step. Use flow steps for the interactions that are part of the scenario, such as filling a field, choosing an option, checking consent or pressing submit.

Keep the scenario short. Each step should explain why the test needs it. A selector that identifies the email field or submit control is easier to diagnose than a long chain of clicks that happens to reach a result. If the page is already in the right state from its URL, do not add interaction just to make the scenario look complete.

• Use stable field and action targets that a reviewer can recognize.
• Add only the headers, cookies and waits the page needs.
• Keep sample values safe, repeatable and clearly non-production.
• Use one scenario for one understandable form outcome.

Assert the visible expectations

A screenshot can show that the form looks complete, but an assertion makes the important expectation explicit. Check that the heading is present, the consent text is visible, the button has the expected label or the success message appears after submission. For a field, assert the value or state that the reviewer needs to trust.

Use visual comparison when the layout itself is part of the risk: a missing field, a broken error panel or a mobile form that no longer fits. Use text and state assertions for the exact copy or value. No-code web testing for pages and UI states shows how to combine these checks without turning every result into a screenshot comparison.

Keep assertions tied to the purpose of the form. Do not assert every decorative label. A smaller set of meaningful expectations survives intentional copy changes and gives a reviewer a clear reason when a run fails.

• Check labels, values, consent copy and success messages that matter.
• Use visual comparison for layout and missing visible regions.
• Keep assertion text specific enough to diagnose a failed run.
• Avoid testing decorative copy that nobody owns.

Test failure and success as separate outcomes

Forms often fail quietly when a validation message disappears or a server error is styled like success. Give the invalid and valid states separate scenarios when both matter. For the invalid state, use a safe incomplete or malformed value and check the visible message. For the valid state, check the success state that a person should see after the form accepts the submission.

Do not treat a button click as proof that the request succeeded. The expected result should be something visible and stable on the page. If the real flow sends data to a third-party service or creates an account, make sure the test data and side effects are acceptable before scheduling the scenario.

• Check that invalid input produces the intended visible feedback.
• Check the success state instead of stopping at the click.
• Use safe test data and understand any external side effect.
• Keep invalid and valid outcomes easy to tell apart in history.

Diagnose a failed form test

When a run fails, first separate a page problem from a setup problem. A missing field can mean the form changed, the page was not ready or the selector no longer matches. A missing success message can mean validation blocked the submission, the response took longer than the wait or the backend returned an error.

Read the run evidence before rewriting the scenario. Check the captured state, the failed assertion and the flow step where the result diverged. Update an expectation only when the product change was intentional. If the form is deliberately different on mobile or by locale, keep those states as separate cases with an owner for each one.

Know when a code test fits better

No-code tests are strongest for visible, repeatable page states that several teams need to review. Use a repository test when the flow needs mocks, generated data, deep branching, private fixtures or merge-blocking control that belongs in engineering code. The two approaches can cover different layers of the same form.

Keep the no-code case when a non-engineering owner needs the rendered result and a short explanation of what changed. Start with the use cases that already match this review style, then schedule the form only when someone is ready to act on its results.

Related links

• No-code website testing
• No-code web testing for pages and UI states
• Use cases
• RenderLog guides

SEO tests need the rendered page, not only metadata

Most SEO checks stop at the obvious fields: title, description, canonical URL, robots tags, and status code. Those fields matter, but they do not show whether the rendered page still contains the pricing table, the localized heading, the FAQ section, or the call to action that search visitors need.

RenderLog fits this gap because it checks public pages after rendering. A team can keep a visual baseline, assert important text, and review the exact page state that a person would inspect before asking Google to crawl it again.

• Confirm that indexable pages still return 200 and are not blocked by robots tags.
• Check that canonical URLs, headings, and visible page copy match the intended page.
• Catch missing localized sections before they reach Google Search Console.
• Review screenshots when a CMS, template, or deployment changes the page layout.

Where no-code autotests help public websites

No-code autotests are useful when a public page has a clear expected state and someone outside engineering owns the result. Product, marketing, support, and SEO teams usually care about the same pages, but they do not always want to maintain Playwright code.

Start with pages where a small change has a visible cost: pricing, signup, comparison pages, API docs, help pages, localized landing pages, and campaign pages. The test should answer a concrete question rather than promise broad coverage.

• Pricing: the plan names, price, billing period, and checkout link are visible.
• Signup: the form fields, consent text, and success state still render.
• Docs: the API example, version note, and page heading are present.
• SEO pages: the title, H1, FAQ, internal links, and canonical route stay stable.

Combine visual checks with text assertions

A screenshot diff is good at showing layout drift, missing sections, and broken responsive states. Text assertions are better when the risk is a specific value: a price, a product name, a legal phrase, a schema-backed FAQ question, or a localized keyword that must stay on the page.

The strongest workflow uses both. Visual comparison tells the reviewer what changed. Assertions make critical content explicit and reduce the chance that a quiet template change removes the words that make the page useful.

• Use visual baselines for page structure, spacing, and responsive layout.
• Use text checks for titles, headings, prices, forms, and FAQ copy.
• Use failure rules to turn known bad states into clear alerts.
• Approve intentional changes from the run so the expected state stays current.

A practical SEO monitoring workflow

A practical workflow starts before publishing. Capture the new page, check the canonical route, inspect the visible content, and confirm that internal links point to the next useful page. After publishing, keep the same page in a scheduled check so template updates, translations, and CMS edits do not silently break it.

This does not replace Google Search Console. Search Console shows how Google discovered and indexed the URL. RenderLog helps keep the page itself healthy before and after that happens.

• Before launch: capture the page and verify the visible content.
• After launch: submit the sitemap and watch the page in Search Console.
• On schedule: rerun checks for pricing, docs, blog, and localized pages.
• After edits: approve the new visual baseline or expected text only when the change is intentional.

Related links

• No-code web testing
• Use cases
• Visual regression comparison
• API docs
• Google Search Central

FAQ

Can RenderLog replace Google Search Console?

No. Google Search Console reports crawl, indexing, and search performance data. RenderLog checks whether the public page still renders the right content, links, and visual state before or after Google crawls it.

What should the first SEO test check?

Start with one indexable page and verify status, canonical route, H1, core visible copy, internal links, and the page section that matters most for conversion or search intent.

Start with the state a person already checks

No-code web testing works best where someone already opens the page by hand before a release. They check the plan price, the signup form, the release banner, the empty state, or the mobile layout that should still hold after a content edit.

The job is not to rebuild a full engineering suite in a UI. The job is to remove repeated manual review and make the expected state readable. Use visual comparison when the whole page matters and assertions when the key risk is a word, a value, or a checked state.

• Pricing page: the plan price and call to action still look right.
• Signup flow: the email field, checkbox state, and success message match expectations.
• Docs page: the version banner and article heading are still visible.
• UI state: the loading, empty, or error view still matches the approved result.

Which pages to cover first

Start where a missed change has a clear cost. For most SaaS teams that means pricing, signup, checkout, docs, onboarding, localized landing pages, and a few reusable UI states that keep breaking quietly.

A good first test answers one simple question. Is the plan still $49? Is the submit button enabled? Did the page reach the success state? Narrow checks are easier to review and easier to update when the product changes on purpose.

• Pick pages with an owner, not pages nobody will review again.
• Prefer visible business risk over broad selector coverage.
• Keep the first version small enough that the result is obvious at a glance.
• Add more assertions only after the first few runs prove useful.

Expected results should update from the run

Real pages change. Prices move, labels get rewritten, and default form states change because the product changed on purpose. A useful review flow lets the team approve the new state from the run instead of sending a non-technical reviewer back into setup.

That is why RenderLog separates visual baselines from assertion expectations. A clean visual run can become the new baseline. A passing assertion run can become the new expected value for the checks that actually ran.

• Approve a deliberate design change without rebuilding the whole check.
• Promote a new expected text or field value directly from the result.
• Keep review history tied to the accepted state.
• Avoid hidden drift between the page and the stored expectation.

When no-code web testing is not the right fit

If a team already owns a deep Playwright suite with fixtures, mocks, and code review, keep that work in code. If the job is only to generate a one-off screenshot or PDF, use the render path instead of saving a recurring check.

No-code web testing fits best when the page has an owner, the expected state is clear, and someone needs a readable result after each release, scheduled run, or client review.

Related links

• Use cases
• Visual regression comparison

FAQ

Is no-code web testing the same as visual regression testing?

No. Visual regression compares screenshots with a baseline. No-code web testing can also check text, values, and checked states without turning every check into a screenshot comparison.

What should a first no-code web test cover?

Start with one page state that someone already checks by hand and that has a real business cost if it ships wrong.

Pricing pages break in ways uptime checks miss

A pricing page is not just a table. It carries plan names, discount labels, checkout links, usage limits, legal notes, and mobile layouts that often fail quietly after a content edit or release.

That is why pricing pages need page-level monitoring, not only uptime checks. A useful run should show the visible page, compare it with the approved state, and make it obvious whether the change is acceptable or a real issue.

• Wrong call to action after a campaign update.
• Shifted mobile comparison table that still returns HTTP 200.
• Stale discount label or crossed-out price.
• Checkout button that points to the wrong flow.

What to monitor first on a pricing page

Do not start with every footnote. Start with the parts that affect trust, revenue, or support load: the headline price, plan comparison, discount state, usage limits, checkout link, and the first payment step.

If pricing changes by locale or market, cover the default locale first and then the markets where copy, currency, or legal notes differ. Concrete checks are easier to review than a vague promise to watch the whole page.

• Plan cards and included limits.
• Currency, billing period, and crossed-out prices.
• Checkout, sign-up, and contact-sales links.
• Mobile layout for long feature rows and sticky buttons.

Where RenderLog fits in the pricing workflow

A screenshot API can capture the page, but the team still has to manage storage, review state, and ownership. A repository-native visual test can catch UI diffs, but pricing decisions usually involve product, marketing, finance, and support, not just engineering.

RenderLog keeps the page capture, approved baseline, run history, and review decision together. That matters when several people need to inspect the same pricing change and agree whether it is ready.

• Capture a clean pricing page before a launch or price update.
• Turn the same setup into a recurring check once the review repeats.
• Approve the new state after a deliberate price or layout change.
• Keep evidence next to the product instead of in ad hoc folders.

Start with one pricing page and one owner

Pick the pricing page or checkout step that already creates review work. Capture it once, approve the clean state, and run the same check after the next copy, pricing, or layout change.

If that run keeps saving manual review time, put it on a schedule. If nobody acts on the result, the problem is not tooling - it is that the page still has no real owner.

Related links

• Scheduled checks
• Pricing

FAQ

Is pricing page monitoring the same as uptime monitoring?

No. Uptime tells you whether the page responds. Pricing page monitoring tells you whether the visible price, plan state, and checkout path still look correct.

What is the first pricing page check worth adding?

Usually the main pricing page or the first checkout step that already gets reviewed by hand before launches or campaigns.

Not every page check deserves an interruption

Monitoring becomes noisy when every successful or low-risk run sends a message. Some checks deserve immediate attention - a failed release check, a missing selector, a login wall, or a critical baseline mismatch. Routine history usually does not.

That is why notification cadence matters as much as the destination. The same team may want instant alerts for broken checkout and a daily summary for stable pricing or docs checks.

• Immediate alerts for urgent failures and blocked states.
• Daily digest for routine successful or low-risk runs.
• No notification for experiments or intentionally unstable pages.
• Use cadence to match the review rhythm, not to maximize message volume.

How teams actually use digests

A marketing team may want one morning summary for landing pages and pricing pages. An agency may batch client-site checks before a weekly report. A product team may keep failed launch checks immediate while successful runs wait for a digest.

That pattern is more useful than a flat stream of notifications. The result stays visible, but the message format matches how the team actually decides.

Use alerts for action and digests for visibility

Send an immediate alert when a person should stop and inspect the run now. Use a digest when the team needs awareness, but the result can wait until the next review window.

That distinction keeps page monitoring useful. A failed checkout check deserves interruption. A stable homepage archive or weekly docs sweep usually belongs in a summary unless it breaks a baseline.

• Immediate alert: failed checkout, blocked sign-up, missing selector, critical baseline mismatch.
• Digest: stable scheduled runs, low-risk pages, recurring client review.
• No alert: ownerless checks or intentionally changing experiments.
• Revisit cadence when the team stops reading the messages.

Set the first notification rhythm around ownership

Keep launch-critical checks on immediate alerts until the team has seen enough clean runs to trust the workflow. Move stable, low-risk runs into a daily digest once short grouped review is enough.

The goal is not to hide problems. The goal is to match the message to the decision so the team sees what matters without turning monitoring into background noise.

Related links

• API docs

FAQ

When should a check send an immediate alert?

Use immediate alerts when the run failing should interrupt someone right away, such as blocked checkout, missing selectors, login walls, or critical baseline mismatches.

When is a daily digest better?

Use a digest when the team needs visibility into routine scheduled checks but does not need a new interruption after every run.

Keep recent history fast by default

Most visual reviews happen soon after the run. That is why recent history should stay quick to scan: the team filters recent days, opens result files, and compares current runs without paying for long-term storage first.

Longer retention matters when older baselines, artifacts, or audit evidence remain useful months later. That is a different job from day-to-day review, and it should be priced and chosen that way.

• Recent history for current QA and launch review.
• Long retention for audits, client reporting, or older baselines.
• Active baselines stay valuable even when the original run is old.
• Do not confuse frequent checks with a need for deep history.

Why longer retention should stay a separate decision

A small team should not have to buy a heavy base plan just to run a few page checks. Longer retention adds value only when the workflow truly needs older evidence, not simply because storage is technically possible.

Keeping retention modular makes the product clearer. Teams can start small, then add deeper history when customer reporting, sign-off workflows, or audits make older runs worth keeping.

Use a business rule, not a storage habit

Stay with recent history if the team only needs to review the latest changes. Add one-year retention when someone will realistically ask how the page looked weeks or months ago and expects the answer to live inside the product.

That often happens around pricing changes, regulated copy, release sign-offs, incident review, and client reporting. If old results never shape decisions, the shorter path stays better.

• Short history for active review loops.
• Long history for evidence and long-lived reference work.
• Choose retention based on retrieval needs, not on capture frequency.
• Upgrade only when older runs become part of normal review.

Choose the retention boundary that matches the workflow

Use the base history while the team is proving the review path. Add one-year retention when older runs become part of approvals, client reporting, audits, or incident investigations.

That keeps the pricing model honest. Teams with only recent review needs stay light, while teams with real long-range history needs pay for the depth they actually use.

Related links

• Pricing

FAQ

Does every team need one-year retention?

No. Most teams can start with recent history and add longer retention only when older runs become part of real approvals, reporting, or audit work.

What happens to active baselines?

Active baselines remain important even if the original run is older than the default visible history window.

Bad runs should fail early instead of pretending to pass

A blocked page is not a successful page. If the run lands on a login wall, CAPTCHA, challenge screen, missing selector, or the wrong view entirely, the result should fail as a wrong state instead of drifting into normal history as if nothing happened.

That protects both visual baselines and assertion history. Otherwise a broken page can quietly become a new accepted result or trigger pointless review on a screenshot that never reached the real page state.

• Login wall instead of the expected page.
• Challenge or CAPTCHA before the browser reaches content.
• Missing selector that proves the page did not load as expected.
• Flow step that breaks before the final review state.

Where failure rules matter most

These rules matter most on pages where a clean screenshot can be misleading: checkout, sign-up, docs behind edge protections, localized pages, or flows that depend on cookies and waits.

The more context a page needs before it becomes reviewable, the more important it is to fail the run on wrong states instead of letting reviewers guess from the final image.

Add the first rule set before you trust the history

Define the obvious blocked states first: missing selector, login wall, challenge page, or broken flow step. Then add more specific rules only where the page truly needs them.

That keeps the run history honest. The point is not to create a giant rule engine. The point is to stop obviously wrong states from looking like real page results.

Related links

• API docs

FAQ

Why not just review the screenshot manually?

Because wrong-state screenshots waste review time and can accidentally become accepted history if the failure is not marked clearly.

What should the first failure rules cover?

Start with the states that clearly prove the browser never reached the intended page: login walls, challenge pages, missing selectors, and broken flow steps.

Use GET for simple calls and POST for real setup

GET fits quick URL-based runs where the page needs little or no context. It is a good first step for one-off captures, simple checks, or a fast proof that the endpoint works.

POST is the better default once the run needs headers, cookies, steps, assertions, labels, storage settings, or a structured body that should be readable later. That is usually where page checks stop being throwaway calls and become part of a workflow.

• GET: fast call with a URL and a few query parameters.
• POST: repeatable run with structured setup and future review in mind.
• GET: good for quick experiments and simple output.
• POST: better for flows, assertions, and saved automation paths.

Why the method changes the product path

The method matters because it often signals the maturity of the work. A GET request usually means a quick run. A POST request usually means the team wants a real recipe that can be understood, reused, and eventually attached to a saved check.

Choosing the right method early keeps the API easier to use. It also keeps the product path clearer: simple render now, richer page check later, without forcing every caller into the same shape.

Choose the first request shape based on the real job

If the job is a fast one-off capture, start with GET. If the job already includes state, assertions, or ownership, start with POST and keep the structure explicit from the beginning.

That split matches how teams actually work. It avoids overbuilding simple calls while keeping more serious page checks readable and stable.

Related links

• API docs

FAQ

When is GET enough?

When the run is simple, mostly URL-based, and does not need much request context or later review.

When should I switch to POST?

Switch when the run needs headers, cookies, steps, assertions, labels, storage settings, or any structured setup that should stay readable over time.

Start with a baseline, not with screenshot churn

A visual diff is only useful when the team knows which state is approved. Without that reference, every new run becomes another screenshot to argue about instead of a decision about whether the page is still acceptable.

That is why baseline review comes first. Approve one clean run, then compare the next runs against that state so the discussion starts from a shared reference instead of from raw image output.

• Approve the page after a deliberate release or design change.
• Use the same baseline for recurring checks on the same surface.
• Replace the baseline only when the team accepts the new state on purpose.
• Keep baseline changes visible in history.

Logs should explain why the run looks wrong

A reviewer should not have to guess whether a failed diff came from the page, the setup, or the environment. Useful logs show the run path, waits, steps, selectors, and visible failures that led to the result.

That context matters even more when the page fails before the final state: login wall, challenge page, missing selector, timeout, or a broken flow step. The visual result alone is often not enough.

• Show the final screenshot next to the step and selector context.
• Keep blocked or wrong-state runs distinct from normal visual changes.
• Make it obvious when the browser never reached the expected page state.
• Use logs to reduce re-runs that only reproduce the same problem.

Alerts should follow ownership, not just failure

An alert is useful only when someone knows the page and can decide what to do next. If the page has no owner, more alerts will not create responsibility - they will only create noise.

Tie alerts to checks that matter now, such as pricing, checkout, launch pages, or client-facing surfaces. Leave lower-risk pages on digest review until the team proves they need interruption-level visibility.

• Immediate alert for critical baseline mismatches or blocked runs.
• Digest review for routine pages with stable history.
• No alert for experiments or pages with intentionally changing content.
• Review ownership before expanding the alert set.

Related links

• Scheduled no-code web tests
• RenderLog product guide

FAQ

What makes a visual diff useful?

It should show what changed, what the approved baseline was, and whether the team should accept the new state or treat it as a regression.

Why do logs matter for visual review?

Because many bad runs come from blocked states, missing selectors, or broken flows, and the screenshot alone does not always explain that.

Schedule a page only when the review already repeats

A page deserves a schedule when someone would otherwise check it by hand on a clear rhythm: after each deployment, every weekday morning, or before the same client review each week.

That is the difference between useful automation and empty activity. The schedule should remove repeated human review work, not create a new stream of runs that nobody reads.

• After-deploy checks for pricing or signup pages.
• Daily monitoring of high-traffic landing pages.
• Weekly review of client sites or docs hubs.
• Recurring checks for brittle onboarding, billing, or UI states.

Store the full recipe, not just the cadence

A useful scheduled check stores more than a cron string. URL, selector, viewport, waits, cookies, request context, flow steps, and assertions all need to stay together.

When that recipe is visible, the reviewer can tell whether the page changed or whether the setup drifted. Without that context, scheduled page checks become hard to trust.

• Keep page target and selector on the saved check itself.
• Save waits, cookies, headers, and assertions with the same setup.
• Pause or resume the schedule without losing review history.
• Run the saved check manually when the team wants an extra pass.

Use schedules where someone will actually react

Scheduled checks fit pages with a clear owner and a stable expected state: pricing pages, marketing pages, docs pages, client deliverables, and key product flows. The run becomes a review item, not another file in storage.

They do not replace code-based testing. Tools like Chromatic or Playwright still fit component-level and repository-native review. RenderLog fits the shared page layer where history and visible ownership matter.

A simple rule that keeps schedules from becoming noise

Do not schedule a page only because it can be captured. Schedule it when the team knows who reads the result and what decision follows a failed or changed run.

That rule keeps automation tied to action. A failed checkout check may deserve an immediate alert. A stable docs page may only need a weekly review. A client site may need one run before a report goes out.

• Set the owner before setting the cadence.
• Use manual runs until the expected state is clear.
• Turn on urgent alerts only for checks that need same-day action.
• Use daily digests for routine pages where grouped review is enough.

Related links

• Manual website captures
• Review diffs, baselines and alerts

FAQ

What should move into a scheduled check first?

Pages or flows that already have an owner, a review rhythm, and a real cost when nobody notices a broken state.

Does a schedule replace code-based testing?

No. It complements code-based tests by covering shared, production-facing, and cross-team page review over time.

Use manual capture when the answer is needed now

Not every page deserves automation on day one. A bug report may need one screenshot. A release candidate may need a before-and-after capture. A client may want to see the current page before a change goes live.

Manual capture is the right first step when the team needs proof immediately and nobody knows yet whether the same setup will repeat. The important part is that the result does not disappear into a random folder.

• Validate a reported layout issue without waiting for a schedule.
• Capture the current state before a release or content change.
• Save a quick visual record for a client or approval thread.
• Check one banner, widget, or table instead of the whole page if that is where the risk lives.

Refine the setup before you save it

A reliable page capture is more than a URL. Real pages often need waits, cookies, headers, a selector, or a click path before the result becomes stable enough to review.

That makes manual capture the best place to tune the recipe. Once it works, the same setup can move into a recurring check without being rebuilt from memory.

• Use full-page capture when the whole screen matters.
• Use selector capture when one component is the unit of review.
• Add waits, cookies, or headers for production-only states.
• Add steps only when the page needs interaction before capture.

Know when to keep it manual and when to schedule it

Keep the workflow manual if the request is rare and nobody needs long-term ownership. That is common for bug reports, one-time client snapshots, or quick release checks that do not repeat.

Move the setup into a scheduled check when the same page keeps coming back. That is when history, baselines, and alerts begin to save time instead of adding ceremony.

• Manual: rare request, no owner, no review rhythm.
• Scheduled: repeated review, approved state, and someone who reacts to changes.
• Repository-native visual tests still fit when the work belongs entirely in code.
• Do not automate a page just because the capture succeeded once.

Related links

• Scheduled no-code web tests
• RenderLog product guide

FAQ

When is manual capture enough?

When the request is occasional and the team does not need a baseline, alerts, or long-term review history.

Can a manual capture become an automation later?

Yes. That is one of the main reasons to start manually and keep the working setup instead of treating the capture as disposable.

What a page check needs after the first run

A screenshot alone rarely answers the next question. Teams still need to know which setup produced it, which run became the approved state, and what should happen when the page changes again.

RenderLog sits between one-off capture and long-term ownership. The same page can start as a manual result, turn into a saved check, and later use baselines, assertions, logs, and alerts without spreading the workflow across folders, threads, and spreadsheets.

• Start with one manual page capture or API run.
• Save the setup once the page becomes a repeating check.
• Approve a visual baseline or expected assertion state from the run itself.
• Keep review history, artifacts, and notifications attached to the page.

Where teams usually start

The first useful page is usually the one that already creates review work: a landing page after CMS edits, a sign-up flow in production, a pricing page before launch, or a client site that needs a current visual record.

Those pages are shared surfaces with visible business impact. They need evidence that can be read by more than one person, not just a developer snapshot buried in a repository.

• Marketing pages and campaign pages that change often.
• Sign-up, billing, or checkout steps with production-only states.
• Docs and localized pages where visible copy matters.
• Client sites that need repeatable before-and-after review.

When a lighter tool is enough

A narrower tool still fits when the team only needs image output or repository-native visual tests. If the full workflow already lives in Playwright snapshots or Chromatic component review, adding a separate page-review workspace may be unnecessary.

RenderLog is a better fit when the problem is ownership around shared pages: approved states, recurring review, result files, and visible history outside one repository.

Build your first review path

Start with manual captures for quick proof, then move to scheduled checks once the same page keeps returning. Add baselines and alerts only after the team agrees what a clean result looks like and who reacts when it changes.

That path keeps the product grounded in real review work instead of turning page checks into another feature list.

Related links

• Manual visual capture
• Render API comparison

FAQ

Is RenderLog only a screenshot API?

No. The API is part of it, but the product also covers saved page checks, approved baselines, assertions, run history, and notification paths for shared website surfaces.

Who gets value first from RenderLog?

Teams that already review shared pages by hand: marketing, product, support, agencies, and anyone responsible for pricing, sign-up, docs, or client-facing screens.