Build a company-wide CI Health Board for our main repo that shows, at a glance, whether CI is currently healthy or broken, and alerts the team when it's blocked. The goal is a shared, always-current view of build health plus proactive notification so a broken main branch gets attention fast. Source the data from our existing CI history records (in our case, two Tines HQ record types — "CI job run" and "Failed tests" — but use whatever CI data store you have: the CI provider's API, a data warehouse, or records/database of job runs and failed tests). Each record is one CI job; many jobs belong to one CI run, so group jobs back into runs and treat a run as failed if any of its jobs failed. Build these pieces: A status API (HTTP route) that returns the current health summary: whether CI is healthy/blocked, the recent runs on the protected branch, per-workflow health, headline stats (24h pass rate, job counts, failing tests), and flaky/repeat-offending tests. Judge "blocked" at the run level — CI is blocked when the most recent N runs of the primary workflow on the protected branch all fail in a row (consecutive failures, since isolated flaky failures self-recover). Prefer server-side aggregation/count queries for the headline numbers over pulling raw rows, and fetch data concurrently, so the endpoint stays fast. A live dashboard (web page) that reads the status API, auto-refreshes, and shows a bold three-state banner — healthy / at-risk (amber, 1–2 consecutive fails) / blocked (red) — with loading states. No time-range control; it answers "is CI OK right now". An analytics API + tab for date-range analysis (presets + custom range): pass-rate trend over time, failures by workflow, top flaky tests, blocked incidents with time-to-recover, and build-duration trend. Keep it scalable over long ranges by using aggregation queries rather than fetching every row; fetch it lazily only when the tab is opened. A scheduled alerter (cron, e.g. every ~15 min during work hours) that detects the blocked condition and posts to your team chat — Slack in our case, or Microsoft Teams / Discord / email — with a link back to the board. Dedupe so it alerts once per incident and posts a recovery note when it clears. A small config endpoint + volume so the alert destination (the chat channel) is editable from the dashboard UI without a redeploy. Trigger model: the dashboard, status API, analytics API, and config API are HTTP routes (space-authenticated); the alerter runs on a cron schedule. Persist alert state and settings in named volumes. Keep everything read-only against the CI data source except the settings the UI writes. Tools used: Tines Records API (record types "CI job run" 5588 and "Failed tests" 10577), Tines Records Query API, Slack API (chat.postMessage), GitHub Actions (CI run/commit links)