> ## Documentation Index > Fetch the complete documentation index at: https://docs.synheart.ai/llms.txt > Use this file to discover all available pages before exploring further. # Metrics explained > How each delivery and repository metric on Insights is counted, where AI shows up in merged PRs, what counts as a production deploy, and what the numbers can't tell you The **Delivery** section on **Insights** at [synapse.synheart.ai](https://synapse.synheart.ai) shows the work your organization shipped, how it moved from idea to production, and where AI was involved. Each card shows one number and one line under it. The ⓘ next to the title gives the short definition. This page has the full version: what goes into each number, what's left out, and why. ![The Delivery section on Insights, showing delivery and engineering measures as cards](https://mintcdn.com/synheartai/bIbSKNEqulE95GhK/images/synapse/metrics-delivery.png?fit=max\&auto=format\&n=bIbSKNEqulE95GhK\&q=85\&s=6ed8c54f00cc3f45efe9c81e096ff31a) The Delivery section on Insights ## Before you read the numbers A few rules apply to every metric on this page. * **No data isn't zero.** If a source hasn't reported, or its history is incomplete, the card is left out or shows a dash. It never shows `0`. A zero means Synapse looked and found none. * **"Observed" means partial.** When Synapse can see some of a period but not all of it (for example, an issue tracker's history only goes back part way), a count card is renamed, say from **Issues completed** to **Issue completions observed**. The number is what Synapse saw, and the real figure may be higher. * **Organization-wide, no contributor floor.** Delivery metrics come from your connected repositories and trackers, not from people's human state, so they aren't held back by the [cohort floor](https://docs.synheart.ai/synapse/team-views.md#the-cohort-floor). They describe the organization's repositories, not individuals. * **Descriptive, not a score.** These are counts and medians of what happened. They aren't productivity targets, they don't rank people, and on their own they don't show that AI caused a change. * **Medians, not averages.** Times and sizes use the median (the middle value), so one PR that sat open for a month doesn't drag the figure. ## Delivery measures These come straight from GitHub, GitLab and your connected issue trackers, across every connected repository. Bots and people who aren't linked to a Synapse member are included, because they still shipped work. | Metric | What it counts | | - | - | | **Issues completed** | Issues finished in the period. Each issue counts once, even if it's reopened and closed again later. | | **Total merged PRs** | Every pull request (GitHub) or merge request (GitLab) merged in the period, including bots, automation and authors not linked to a member. PRs with impossible timestamps, such as merged before they were opened, are left out. | | **Production deployments** | Successful deploys to production, using what you've told Synapse counts as production. See [Production deploys](#production-deploys). | | **PR lead time** | The typical (median) time from opening a PR to merging it, over the same PRs as **Total merged PRs**. It isn't commit-to-production time. | | **Issues created** | New issues opened in your connected trackers in the period. | | **Production-branch merges** | PRs merged into a branch you've marked as production. A merge isn't a deploy: code can land on `main` and wait for a release. | | **Time to first human review** | The typical wait from opening a PR to its first review by someone other than the author, and not a bot. Only reviews before the merge count. PRs that were merged with no human review are left out, rather than counted as an instant review. | | **CI success rate** | The share of CI runs that passed. Only the latest attempt of each run counts, so a flaky job that passes on retry counts once, as a pass. Timeouts and runs that failed to start count as failures. Canceled, skipped and still-pending runs are left out. | ## Engineering measures These describe the human side of code review and shipping. They count PRs by people with a GitHub or GitLab account linked to their Synapse membership. Bots and draft PRs are left out. | Metric | What it counts | | - | - | | **PR cycle time** | The median time from opening to merging, for human-authored PRs by linked contributors. It's shown only when the repository-wide **PR lead time** has no value. | | **Merged PRs per week** | How many human-authored PRs merged each week. It's a description of pace, not a target or an AI effect. | | **PRs per engineer** | Merged PRs per engineer per week. Every member with a linked GitHub or GitLab account counts for the whole week, including weeks they didn't open a PR. | | **PR size** | The median of lines added plus lines deleted per merged PR. The ⓘ also shows the median number of files changed. | | **Review load** | The average number of reviews on each merged PR, leaving out self-reviews and bots. The ⓘ also shows the average number of distinct reviewers. | | **Production deploys per week** | The weekly median of production deploys. The ⓘ also shows the daily rate. | > [!TIP] > > Engineering measures only include people whose code accounts are linked. If a number looks low, check that your developers have linked their GitHub or GitLab accounts. See [Developer setup](https://docs.synheart.ai/synapse/developer-setup.md). ## Production deploys Synapse doesn't guess which of your branches and environments are production. You tell it, one repository at a time, and **Production deployments**, **Production-branch merges** and **Production deploys per week** follow that setting. To set it up, go to **Connectors**, open **GitHub** or **GitLab**, and find **Production delivery**. Only owners and admins can change it. Everyone else sees it read-only. ![The Production delivery settings in the GitHub connector, with production branches, the deploy source and the webhook status](https://mintcdn.com/synheartai/bIbSKNEqulE95GhK/images/synapse/metrics-production-delivery.png?fit=max\&auto=format\&n=bIbSKNEqulE95GhK\&q=85\&s=db014650a044e8e36758d8684e396123) Production delivery settings for one repository, in Connectors For each repository: 1. **Production branches.** Choose the branches that count as production. Merges into these count as **Production-branch merges**. Synapse suggests the repository's default branch, but nothing counts until you save. 2. **Count deploys from.** Choose one of two sources: * **Deployments to production environments.** Use this if you record deployments in GitHub or GitLab, for example GitHub Environments. Pick the environments that are production. Each successful deploy to one of them counts. CI runs don't. * **Selected CI workflows.** Use this if a CI job does your deploy. Pick the workflows that deploy to production: workflow file paths on GitHub (such as `.github/workflows/deploy.yml`), or exact pipeline names on GitLab. A successful latest run of one of those workflows, on a production branch, counts as a deploy. Saving confirms that these workflows really deploy to production. 3. **Save delivery policy.** Each repository uses one source only, so the same release is never counted twice. Repositories you haven't set up don't add to production metrics. **Webhook.** Below the settings, Synapse shows whether live updates from the provider are arriving. If they stop, scheduled syncs still keep the data up to date, just less often. On GitLab, live updates need the `api` scope and Maintainer access to the project. If you connected GitLab with `read_api` only, reconnect it. ## AI PR attribution **Repository AI evidence**, under Delivery, shows where AI shows up in the PRs your organization merged. It looks for signs that AI wrote or helped with a PR. It can't prove that code was generated, and a PR with no sign of AI wasn't necessarily written without it. ![Repository AI evidence, with merged PRs split by AI attribution and by author account type, and the count of AI coauthored PRs](https://mintcdn.com/synheartai/bIbSKNEqulE95GhK/images/synapse/metrics-ai-attribution.png?fit=max\&auto=format\&n=bIbSKNEqulE95GhK\&q=85\&s=ecf4caf14e4ae1f2e85756d189ada5f1) Repository AI evidence on Insights ### AI attribution Every merged PR falls into exactly one group. When a PR has more than one sign, the strongest one wins. | Group | What puts a PR here | | - | - | | **Agent-authored PRs** | The PR was opened by a coding agent's own bot account on GitHub or GitLab, such as the Copilot coding agent, Claude, Codex, Cursor, Devin or Gemini Code Assist. | | **Declared assistance** | Someone said AI helped: a declaration line at the end of the PR description (for example *Generated with Claude Code*), an `ai-assisted` or `ai-generated` label, or an AI `Co-authored-by`, `Generated-by` or `Assisted-by` trailer on a commit. | | **AI hints only** | Weaker signs with no declaration: a branch named after an agent (such as `claude/…` or `codex/…`), or commits authored from an AI company's email domain. | | **Unknown AI attribution** | No sign either way. That doesn't mean the PR was human-only. Many people use AI without leaving a trace. | Synapse is strict about what counts as a declaration. A line has to be a declaration on its own, at the end of the PR description or in a commit's trailer block. A sentence such as "we didn't use Copilot here", or an example in a code block, doesn't count. The four groups always add up to all merged PRs, so you can read them as shares. ### PR author account type The same merged PRs, split a second way: by who opened them. * **User accounts:** a person's account. * **Automation accounts:** bots and service accounts, including coding agents and dependency bots. * **Unknown account type:** the provider didn't say. This is a separate question from AI attribution. A PR from a user account can still be AI-assisted, and generic bots like Dependabot aren't counted as AI. ### AI coauthored PRs A count of merged PRs with at least one commit carrying an AI `Co-authored-by` trailer, which many coding agents add by default. Each PR counts once. Other kinds of declaration don't count toward this figure, and PRs Synapse could only partly inspect can't be counted as having none. ### What Synapse reads, and what it keeps To classify a PR, Synapse reads the PR's author, labels, description, branch name, commit messages and commit author email domains, as your connector allows. It keeps only the result: the group, the tool name (such as `claude-code`) and how the signal was found. It doesn't store descriptions, commit messages or email addresses. On very large PRs it reads the first 256 commits and marks the result as partial. ## What these numbers can't tell you * **That AI caused a change.** A rise in merged PRs alongside a rise in agent-authored PRs is a pattern, not proof. * **How much code AI wrote.** Attribution is per PR, not per line. * **How productive a person is.** Synapse doesn't rank people by these metrics, and it shouldn't be used to. * **Anything outside connected repositories.** If a repository isn't connected, or the provider's history is incomplete, its work is missing. For how team figures from human state are protected, see [Team views and privacy](https://docs.synheart.ai/synapse/team-views.md). For where AI spend comes from, see [AI spend](https://docs.synheart.ai/synapse/ai-spend.md). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.