Glossary

CI history window

A CI history window is the span of past pipeline data a tool lets you analyze. Why the window size decides which trends you can see — and which you cannot.

What is a CI history window?

A CI history window is the span of past pipeline data a CI analytics tool retains and lets you query — the maximum lookback available to dashboards, trend lines, and reports. A 7-day window answers "what broke this week"; only a longer one can answer "is this getting worse".

How it works

Three properties define a window, and vendors vary on all of them:

Property The question it answers
Length How far back can I look — days, weeks, months?
Backfill On connect, does the tool import existing history or start empty?
What happens past the edge Is old data deleted, or merely hidden from view?

Length differs by orders of magnitude across tools and plan tiers — some free plans retain barely a day of data (Mergify's free tier is 24 hours, as of 2026-07-28) while enterprise observability platforms keep pipeline history for over a year — Datadog retains pipeline, stage and job data for 15 months (as of 2026-07-28) — so it is one of the first things to check when comparing tools (the Datadog and Mergify comparisons list verified retention figures). Backfill decides whether you see trends on day one or wait weeks for data to accumulate. The past-the-edge behavior is the quiet one: deletion means a downgrade or lapsed trial destroys history, while a pure visibility clamp means the data survives and reappears when the window widens.

Why it matters

Most of the metrics worth tracking are only meaningful against a baseline, and the baseline lives in the window:

  • Trend direction. Whether a failure rate of 12% is a crisis or a recovery depends entirely on what the prior weeks looked like.
  • Flaky vs broken. Separating flaky tests from genuine regressions requires seeing the same job pass and fail across many runs — a short window rarely holds enough samples.
  • Slow drifts. Duration percentiles creeping up 2% a week are invisible in any single week.
  • Sparse events. MTTR and change failure rate average over incidents, and a small team may see only a handful per month — a window shorter than the gap between incidents produces noise, not a metric.

The practical rule: the window must be several times longer than the cycle of the pattern you are trying to see. Weekly release rhythm needs a month or more of history; monthly patterns need a quarter.

TrimCI treats plan limits as visibility windows in the strict sense — synced runs are never deleted and syncing never stops, so a wider plan window immediately exposes history that was already there. The per-plan window lengths, and the 60-day maximum lookback that currently bounds all of them, are listed on the pricing page.

← All CI/CD terms

schedule Fast setup · 14-day free trial

See what your CI failures actually cost.

Connect GitHub Actions or GitLab CI with read-only access — never your source code — and get a ranked, dollar-costed fix list from your own pipeline data.