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. 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.
See what your CI failures actually cost.
Connect GitHub Actions or GitLab CI with read-only access — we never request repository contents, only pipeline runs, jobs and failed-job log excerpts — and get a ranked, dollar-costed fix list from your own data.