🇺🇦
3 min read

Retention filters for recent and one-year history

RenderLog keeps recent run history fast by default and adds one-year retention when teams need older result files, baselines and audit evidence.

run historyretention
On this page
  1. Recent history by default, longer history when it matters
  2. Why longer retention is a scale module
  3. The decision rule
  4. Choose the retention boundary

Use this when

  • Base history focuses on the last 30 days.
  • Retention 1 Year extends filters and result access to 365 days.
  • Active baselines stay protected even when the source run is older than the visible range.
Retention filters for recent and one-year history

Recent history by default, longer history when it matters

Most visual checks are reviewed soon after they run. The base workspace keeps that recent window light: teams can filter the last 30 days, open result files and compare runs without paying for long storage before they need it.

One-year retention is for teams that need a longer audit trail. It keeps older result files, previews, logs and baseline context available for release reviews, client reporting and regulated work where a page state may matter months later.

Why longer retention is a scale module

RenderLog pricing stays modular by design. A small team should not need a large base plan to run a few screenshots, PDFs or scheduled checks. Longer retention adds storage and review depth only when the team proves it needs that history.

A team can start with successful runs, then add retention later when baselines, reports or audits make older history necessary.

The decision rule

Keep the default history when the team only needs to review the latest change. Add one-year retention when someone will ask what the page looked like weeks or months ago and the answer must come from the product, not from exported files.

That usually happens after pricing changes, client approvals, release sign-off, incident reviews or regulated content updates. If nobody will use older results to make a decision, the lighter model is still the better fit.

  • Use base history for recent visual QA and normal website monitoring.
  • Use one-year retention for audit evidence, client reporting and long-lived baselines.
  • Do not buy longer history just because the page is checked often. Frequency and retention solve different problems.

Choose the retention boundary

Use base retention while the page only needs recent review. Add one-year history when the same page becomes part of audits, client reporting, long-running release checks or pricing evidence.

This keeps pricing honest. The product can begin with successful runs and recent history, then keep older result files only for pages where old evidence has real value.

Related links

Pricing

FAQ

Do all teams need one-year retention?
No. Most teams can start with recent history and add one-year retention when reports, audits or older baselines become part of the review process.
What happens to active baselines?
Active baselines stay protected even when the source run is older than the default visible range.