Review visual diffs with baselines and ownership
Use baselines, visual diffs, run logs and alerts to separate accepted website changes from regressions that need action.
On this page
Use this when
- A baseline marks the state the team has accepted.
- A new run becomes easier to judge because the reference is explicit.
- The decision is attached to the same page history, not scattered across chat or email.
Start with a baseline, not with noise
A single result only tells you what a page looked like once. A baseline adds the missing reference: the state the team already accepted.
RenderLog lets a team promote a finished run to baseline and keep that decision tied to the same automation. Review stays grounded because everyone can see the current image, the approved image and the difference between them.
Logs should answer the next question quickly
Run history should answer the next question without sending the reviewer across several tools. Which automation ran? Did it pass? How long did it take? Which image is the baseline?
That is where review differs from pure rendering. A capture service can stop at the image. A page review needs enough context for another person to step in later and understand the result.
Alerts should follow ownership
Send an alert only when somebody owns the page and knows what to do next. Pricing pages, signup flows, recurring client pages and release paths are good candidates because a visible change should trigger a real review.
When ownership is missing, alerts turn into noise. Build the page history and baseline habit first, then add alerts where the review path is already clear. Shared page operations need this context; capture-only utilities usually stop at the file.
- Use alerts where a visible regression should trigger action quickly.
- Avoid noisy alerting on pages that are intentionally unstable.
- Treat history and baselines as the foundation for alerts, not an optional extra.