diagnosing-ci-and-merge-bottlenecks

name

diagnosing-ci-and-merge-bottlenecks

description

Diagnoses CI and pull-request pipeline health for a GitHub repo using the engineering analytics MCP tools — pull-requests (PR list with CI status), workflow-health (per-workflow CI trends), and pr-lifecycle (a single PR's timeline). Use when asked whether CI is getting faster or slower, which GitHub Actions workflow is the slow or flaky long-pole, how long PRs take from open to merge, how an author's merge time compares to the cohort, which open PRs have failing or pending CI, or where a specific pull request is stuck. Triggers on "engineering analytics", "is CI getting slower", "slow workflow", "flaky CI", "time to merge", "cycle time", "PR throughput", "failing checks", "where is PR <n> stuck", "CI long pole", "what's holding up this PR".

Diagnosing CI and merge bottlenecks

Engineering analytics treats a pull request like product analytics treats a user: a PR moves through a pipeline (opened → CI → review → merged → deployed) and the job is to find where it slows down. The surface is three named MCP tools — you call them, you don't write SQL. Dogfooded on PostHog/posthog; the same tools serve autonomous agents (e.g. PostHog Code) reasoning about their own PRs.

The tools

• pull-requests — the PR workhorse. Open PRs plus anything merged or closed since date_from (default -30d), newest first. Each row carries author (nested object: handle, display_name, is_bot), repo (nested: owner, name), state, is_draft, labels, open_to_merge_seconds, and a ci rollup (runs / passing / / ) from the head-SHA join. Answers most PR-level questions: which PRs have failing or pending CI, which are stuck open longest, per-author or per-repo triage, and time-to-merge stats (aggregate over the returned merged rows yourself — median and p95, never a mean).