> ## Documentation Index > Fetch the complete documentation index at: https://opensre.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # CI/CD analytics demo > See how reliable your CI is and how much developer time it costs, using real repositories on your machine. ## Overview On every interactive launch OpenSRE asks which demo to run. The recommended option analyzes a real repository from your machine and reports CI/CD reliability KPIs, including the developer time lost to unreliable CI. That analysis is read-only and takes a couple of minutes. The other choices set up a recurring CI/CD agent, show the upcoming managed service, or connect Slack. Press Escape to skip, or use the custom-answer row to type a different request. Run it again at any time with `/demo`, or by asking: ```text theme={null} run the CI/CD analytics demo analyze Tracer-Cloud/opensre CI/CD performance how much developer time does flaky CI cost us ``` ## Prerequisites * `git` on `PATH` * A GitHub token that can read Actions history (`opensre integrations setup github`, or `GITHUB_TOKEN`) ## What happens The agent guides you through the selected demo in the shell. 1. **Scan.** It scans your home directory for git checkouts and paints a bar chart of the last 30 days of commits, your own contributions first. 2. **Pick a repository.** A menu lists your checkouts that have GitHub Actions workflows, then the open-source example, then a row to type your own. 3. **Analyze.** It reads the repository's Actions history for the last 30 days and paints the report: one sentence on what waiting on CI cost, the key results, then a comparison table against langchain-ai/langchain and anomalyco/opencode. The benchmark columns ship with OpenSRE and name the day they were measured. Every analysis reads GitHub; nothing is answered from a cache. 4. **Next step.** A menu offers the CI reliability agent (it schedules the check for the repository you just analyzed, no second repository question), the Slack hand-off, or exit. Typing a request such as `analyze owner/repo CI/CD performance for the last 30 days` skips the scan and repository picker. ## The KPIs | KPI | Meaning | | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | GitHub Actions executions | Completed runs on the default branch and on pull requests in the window | | PR-triggered failed workflows and failure rate | Pull request runs that failed, including runs that only passed after a re-run | | CI reliability failures | Failures where the identical commit passed later, by re-run or a fresh run. CI, not the code, was at fault | | Source-code failures | Failures that passed only after the branch moved to a new commit | | Developer downtime from unreliable CI | The working-hours part of the wait below, attributed to each PR's author, with the heaviest-hit developers in hours per week | | Wall-clock wait on merged PRs | Per merged PR: how much later its commits went green than they would have had CI run normally. For each commit with a CI reliability failure, the expected green time is the first queued run plus the slowest workflow's normal duration; the actual green time is when its last workflow passed | | Normal duration | Per workflow, the median duration of first-attempt passing runs | | Default-branch red time | Hours during which the latest commit on the default branch had a failing push-triggered check, with mean time to recovery; the red time is attributed per workflow so one failing scan is not mistaken for a broken build | Only PRs that were merged count toward blocked time, so the number reflects delays that sat on the path to a real merge. Workflows that fail and recover in parallel on the same commit count once, a commit's wait ends when the next commit of the same PR is pushed or the PR merges, and a commit whose workflows never all passed is left out. A later commit that triggered no workflow is invisible; the merge time still bounds the wait. When GitHub omits a PR number, the run belongs to the first later merge of that head repository and branch. When it attaches several, the run belongs to the merged PR whose lifetime contains the run. Developer downtime is the part of each wait that falls inside working hours: Monday to Friday, 09:00 to 18:00 in this machine's timezone, printed with the figure. A re-run that happened over a weekend adds wall-clock wait but no downtime. Each blocked PR is attributed to its author, so the report can say how many hours a week the heaviest-hit developers lost. The report shows the calculation, not only its result. It states the formula (expected green = first run queued + normal duration; blocked = actually green minus expected green, in working hours), then a table of the most blocked PRs with their author, queue time, normal duration, expected and actual green times, and the working-hours and wall-clock wait, then the sum across all blocked PRs, the division by the developers affected, the per-week figure, and the heaviest-hit developers. The wall-clock total across PRs not merged yet is shown when it differs. ## The CI reliability agent Pick "Set up an agent that improves CI/CD reliability over time" from the startup menu to analyze the repository now, then schedule that report as a recurring check. The demo scans your machine, asks which repository to watch, reads GitHub Actions (a token is required), and creates the loop (weekdays at 08:00 local time by default). Choosing this option after an analytics report schedules that repository without asking you to pick it again. Every later run analyzes the last 7 days; use `/loops run ` to run it now. * Reports land in this shell's inbox: `/loops messages`. The loop never posts to Slack or any chat channel, even when those integrations are configured. * Manage it with `/loops list`, `/loops stop `, and `/loops delete `. * Each run is deterministic: no model turn sits between the schedule and the report, and the raw figures are saved as JSON next to the report path named at the end of every delivery, under `~/.opensre/ci_reliability_reports/`. * The loop fires while the shell is open. To keep it running when the shell is closed, run `/loops service install`; it installs a per-user service (launchd on macOS, systemd on Linux) that starts at login. `/loops service remove` deletes it. Windows is not supported yet; run `opensre cron start --service` from Task Scheduler instead. * Running the demo again for the same repository reuses the existing loop. ## Limits * Windows up to 90 days. Each scope reads at most 2,000 runs; the report says so when a cap was hit. * Merged PR detection covers the 500 most recently updated closed PRs. * Scheduled and manually dispatched workflows count toward executions but not toward default-branch red time. ## Troubleshooting | Symptom | Fix | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------- | | **"GitHub token is required"** | Run `opensre integrations setup github` and rerun the demo | | **No repositories offered** | None of the checkouts under your home directory has a GitHub origin and a `.github/workflows` folder; pick the example repository | | **The picker did not appear** | It needs an interactive TTY. Run `uv run opensre` in a terminal, or type `/demo` |