Reading the dashboard
Understand estimated loss, failure rate, the failure calendar, and the per-repository breakdowns — and how to switch the analysis window.
The dashboard is TrimCI's home page: one screen that answers "how healthy were our pipelines in the last N days, and what did the failures cost?". Every number on it — hero cards, loss estimate, calendar, tables — recomputes for the time window you select, so the page always tells one consistent story.
Simplified illustration — the real screens hold more detail, but the labels and steps match the app.
Step by step
-
Pick your window
The filter bar at the top offers three window chips — last 7, 30, and 60 days. Which chips are unlocked depends on your plan's history window: 7 days on Free, 30 days on Team, 60 days on Business (and during the trial). Locked ranges show a lock icon; your choice is remembered between visits, and "Reset filters" returns everything to defaults.
-
Read the hero cards
Four cards headline the window: Total Runs, Failure Rate, Success Rate, and Avg Duration (split into success vs. failed averages). Each carries a sparkline, and the first three also show a trend chip labelled "vs prior period" when the prior window has data — comparing against a window of the same length immediately before the current one. With two or more providers connected, Avg Duration shows per-provider figures instead of one blended number (and drops its sparkline), because providers measure duration differently.
-
Understand the estimated loss
The "Estimated loss" card prices the failures actually observed in the window — no projection. Each failed run is assumed to cost 40 engineer-minutes at your organization's hourly rate, plus a 15% rework tax on that labor. The card breaks this down into engineer-hours, debug labor, and rework tax, shows a per-developer split, and compares against the prior period. The header links to Settings, where you set the hourly rate and developer count the math uses.
-
Scan the failure calendar
"Failure pattern" shades each day by how many runs failed, from "Fewer" to "More". A 7-day window renders as a horizontal day strip; longer windows render a month grid with previous/next arrows to page through earlier months inside the window. Clusters jump out — a dark Monday column, a bad release week — and the calendar follows the conclusion filter if you narrow it to, say, timeouts.
-
Drill into repositories
"Repository Breakdown" lists every repo with completed runs in the window: totals, failed runs, failure rate, a trend sparkline, average duration, time of the last failure, and that repo's share of the estimated loss. Most columns are sortable — repository, totals, failure rate, duration, and last failure — and a search box appears once the list grows. Deactivated repositories are excluded from live analytics, but their history is preserved for reports.
-
Triage recent failures
"Recent Failures" lists failed runs newest-first, with a stacked bar showing the mix of failure types (failed, cancelled, timed out, startup failure). Use the Conclusion select in the filter bar to isolate one type, or "Group by pipeline" to collapse the list into pipeline-and-branch groups so one flaky workflow doesn't drown out the rest. With two or more providers connected, "Provider Health" cards appear on the side — click one to filter the whole page to that provider.
Failure and success rates use decisive runs as the denominator: failures plus successes. Skipped and neutral runs are excluded, so Failure Rate may not equal Failed ÷ Total — and the two rates always sum to 100%. Cancelled runs count as failures on purpose: a cancellation is almost always a symptom of a failure already in flight, and its debugging time belongs in the same bill.
The loss estimate is only as good as its inputs. Open Settings and set your real blended hourly rate and developer count — the rate starts at a generic default and the developer count falls back to your member count until you override them; the card header shows exactly which rate and headcount it used.
The "Updated X ago" stamp under the title reflects the most recent pipeline sync. If it is older than 36 hours, a "Data may be stale" banner appears — usually a sign the provider connection needs attention. See the troubleshooting chapter for how to diagnose a paused sync.