# Importing Your Team Source: https://docs.devperform.io/admin/import-members Seed your engineer roster from your org / group / workspace in one click. Rather than adding engineers one by one, an admin can import your entire team — every member of your connected GitHub org, GitLab group, or Bitbucket workspace — to seed the roster. ## How to import 1. Go to **Admin → Engineer Roster**. 2. Click **Import your team**. 3. DevPerform reads your members and creates an engineer for each, with their handle (and name + avatar) attached. **Emails** are filled in automatically from commit metadata — the reliable source across every host and on private repos, since the member APIs rarely expose email. Imported engineers start **ungrouped** — they appear under an **Unassigned** view until you assign them to [teams](/concepts/teams). DevPerform deliberately does *not* invent a placeholder "Engineering" team for you; the Unassigned view is just a prompt to organize people into the real teams you want. The import is **idempotent** and case-insensitive on handles, so running it again won't create duplicates — it only adds members who aren't already on the roster. Run it again after your team grows to pull in new hires. ## Requirements * You must be an **admin**. * At least one repo must be configured, so DevPerform knows which org / group / workspace to read. * DevPerform needs **member-read access**: the GitHub App (or OAuth) for GitHub, and the stored OAuth token for GitLab/Bitbucket. If the import returns a permissions error, re-authorize the connection or contact us. ## After importing Imported engineers behave exactly like manually-added ones: assign them to teams, add additional [handles](/concepts/engineers) if they use multiple accounts, and they'll start showing up in metrics as their PR/MR activity syncs. # Admin Setup Source: https://docs.devperform.io/admin/setup Configuring repos, engineers, teams, and org settings from the Admin panel. The Admin panel is accessible to admins — the user who connected the code host is made an admin (and account owner) automatically, and can grant the role to others by sending an **Admin** invite from **Admin → People & Teams**. It's where you configure everything DevPerform needs to ingest data and display your team. ## Org settings Under **Admin → Org Settings** you can configure: * **Organization name** — the display name shown across the app. * **Burnout threshold** — the open-PR count that triggers the protective 🔥 overload flag in the team table. Default is **5**. * **Deploy detection mode** — how [DORA](/metrics/dora) detects deploys: **merges** to the default branch (default, zero-config) or real deploys (GitHub Actions workflow runs / GitLab / Bitbucket Deployments). In actions mode, set the workflow or environment name. * **Incident label** — the issue label DevPerform treats as an incident (GitHub/GitLab labels; Bitbucket matches on title), used for DORA change-failure-rate and time-to-restore. * **Survey anonymity threshold** — the minimum responses before [survey results](/surveys/results) are revealed. Default is **4**. ## Repos Add repos as `owner/repo` — GitHub org/repo, GitLab `group/project`, or Bitbucket `workspace/repo` (e.g. `acme/backend`). Connecting GitLab or Bitbucket auto-tracks your accessible repos, so this is mainly for GitHub or extras. All tracked repos are analyzed together for a given date range. Removing a repo only stops DevPerform tracking it — nothing changes on your code host. Adding a repo kicks off an immediate background sync. ## Engineer roster Add engineers with a name and at least one handle, or **import your whole org / group / workspace at once** — see [Importing your team](/admin/import-members). For surveys, also map each engineer's **work email** (emails are also auto-filled from commit metadata). See [Engineer Roster](/concepts/engineers) for multiple handles and deactivation. ## Teams Create a nested team hierarchy to enable team filtering. Teams are optional — skip it and all engineers appear together. See [Teams](/concepts/teams). ## Permissions The admin can add/remove repos, manage engineers and handles, manage teams, and update org settings. Regular (non-admin) users can view dashboards but not the Admin panel. # Single sign-on (SSO) Source: https://docs.devperform.io/admin/sso Let your team sign in through Okta, Microsoft Entra, Google Workspace, or any SAML 2.0 identity provider DevPerform supports corporate single sign-on for teams that manage access through an identity provider. Two options, usable together: * **OIDC** — Okta, Microsoft Entra ID, Google Workspace, OneLogin, JumpCloud, or any OpenID Connect provider. * **SAML 2.0** — for identity providers that require SAML. Only the **account owner** can configure SSO, under **Admin → Settings → Single sign-on**. ## Set up an OIDC provider (Okta, Entra, Google Workspace) 1. In your IdP, create a **Web** application with the redirect URI shown in DevPerform's SSO settings (`https://devperform.io/api/auth/oidc/callback`). 2. In DevPerform, choose **Add identity provider → OIDC** and enter: * **Issuer URL** — e.g. `https://yourcompany.okta.com`, or for Entra `https://login.microsoftonline.com//v2.0` * **Client ID** and **Client secret** from the app you created * **Email domains** — the company domains your people sign in with 3. Save. DevPerform validates the issuer immediately, so a typo fails at setup time — not at your team's first login. ## Set up a SAML provider 1. In DevPerform, choose **Add identity provider → SAML 2.0** and enter your IdP's **Entity ID**, **SSO URL**, and **signing certificate** (PEM). 2. Configure your IdP with the values DevPerform shows on the provider card: **SP Entity ID**, **ACS URL**, and the **SP metadata URL** (importable). 3. Have the IdP send the user's email as the **NameID** (email format). ## How your team signs in On the sign-in page, choose **Sign in with company SSO** and enter a work email. The email's domain routes to your identity provider; after authenticating there, the user lands in DevPerform. ## Auto-join (JIT provisioning) With **auto-join** enabled on a provider, the first sign-in from a verified email on one of your domains joins your account automatically as a **member** — no invitation needed. Role changes (admin, owner) stay explicit in **Admin → Members**. ## Linking SSO to your existing account If you created your DevPerform account with GitHub, GitLab, or Bitbucket and later want to sign in through your company's SSO **as the same account** (not a new one), link it: go to **Admin → Settings → Single sign-on → My login methods**, click **Link \[your provider]**, and complete the SSO sign-in. From then on, signing in through that identity logs you into your existing account with your existing role — no duplicate. You can unlink a login method anytime from the same panel. For security, an SSO identity can only be linked by you while you're already signed in, and it can't be linked if it already belongs to another user. ## Require SSO The account owner can require SSO for members: sign-ins via GitHub, GitLab, or Bitbucket are then refused for members of your account and pointed at the SSO flow. The owner is always exempt, so a misconfigured provider can never lock the account. ## Notes * Each email domain can be claimed by only one SSO configuration. * Shared mail domains (gmail.com and similar) can't be used as SSO domains. * Removing a provider doesn't delete the users who signed in through it — they keep their accounts and can use another sign-in method. # CSV & API Data Export Source: https://docs.devperform.io/api-data-export Pull your metric data into a BI warehouse with account-scoped API tokens. Data export is part of the **Pro** plan. See [Plans](/plans). Export the metric data behind your dashboards as **CSV or JSON** — for a BI warehouse, a spreadsheet, or your own analysis. ## Create a token 1. Go to **Admin → Settings → API & Exports**. 2. **Create token**, give it a name (e.g. "warehouse-sync"). 3. Copy the `dpx_…` token — it is shown **once**. DevPerform stores only a hash. 4. Revoke any token from the same card; revoked tokens stop working immediately. ## Authenticate and pull ```bash theme={null} curl -H "Authorization: Bearer dpx_YOUR_TOKEN" \ "https://devperform.io/api/export/v1/pull_requests.csv?from=2026-04-01&to=2026-07-01" ``` ## Datasets | File | What's in it | | -------------------- | ------------------------------------------------------------------------------------------------------------------- | | `pull_requests.csv` | Merged/closed PRs: repo, author, timestamps, sizes, review counts, cycle hours, AI attribution, investment category | | `commits.csv` | Commit metadata: SHA, PR, timestamps, sizes, AI attribution | | `deployments.csv` | Deployments as ingested | | `incidents.csv` | Incidents as ingested | | `teams.csv` | Team rollups — engineer **counts**, not member lists | | `metrics_weekly.csv` | Weekly per-team trend aggregates (cycle time, throughput, review health) | **Parameters:** `from` / `to` (ISO dates, default last 90 days) · `format=json` for JSON instead of CSV. **Rate limit:** 60 requests per hour per token. Unknown or revoked tokens get `401`; throttled requests get `429`. ## What's deliberately not exportable The export mirrors what's already visible in the app and in your git history. Per-engineer PR and commit rows are included (that's public git metadata, shown in-app). **Never exportable:** survey answers, per-person survey data, or derived per-person scores — the same team-level design the whole product follows. # AI Assistant Source: https://docs.devperform.io/assistant Ask plain-English questions about your product setup — and about your own delivery data. The assistant is part of the **Growth** plan and above. See [Plans](/plans). The in-app assistant (bottom-right of every app page) answers two kinds of questions: * **Product questions** — "how do I connect GitLab?", "what does pickup time mean?" — answered from this documentation. * **Your data** — "How did cycle time trend this month?", "What's our investment mix this quarter?", "Which team has the slowest review pickup?" — answered from your account's live metrics, the same numbers the dashboards show. ## Answers you can check Every data answer ends with a **link to the dashboard that shows those numbers**, so you can verify rather than trust. The assistant reads through the exact same account-scoped metric services as the dashboards — there is no separate compute path to drift. ## What it won't do — by design * **Rank individuals.** Ask "who's my slowest engineer?" and it will decline and offer the team-health views instead — activity counts aren't a measure of individual performance, and the whole product is built team-level. * **Peek behind anonymity.** Survey questions honour the same anonymity thresholds as the survey dashboards; below the threshold it tells you results are hidden and why. # Bitbucket Setup Source: https://docs.devperform.io/bitbucket-setup Connect a Bitbucket Cloud workspace. DevPerform reads pull requests, approvals, and commits from Bitbucket Cloud to compute the same metrics it does for GitHub and GitLab. ## Connect Bitbucket 1. Sign in to DevPerform (with Bitbucket, or any provider). 2. In **Admin → Connect a code host**, click **Connect Bitbucket**. 3. Authorize DevPerform on the Bitbucket consent screen — **read-only** access to your account, repositories, and pull requests. 4. DevPerform creates your workspace, auto-tracks accessible repos, and starts syncing. Connecting Bitbucket also signs you in — a Bitbucket-only team never needs a GitHub account. ## What gets read * Pull requests + approvals, comments, commits, and diffs (cycle time, review health, churn) * Deployments and issues (for DORA — optional; issue tracking needs the `issue` read scope) * Workspace members (for the one-click team import) Read-only throughout. ## Notes * **Bitbucket Cloud** (bitbucket.org) is supported today. Self-hosted Bitbucket Data Center uses a different API — [contact us](mailto:sales@devperform.io) if you need it. * Bitbucket doesn't expose member emails via its API, so DevPerform fills engineer emails from commit metadata instead — no manual entry needed. # Engineer Roster Source: https://docs.devperform.io/concepts/engineers How DevPerform identifies engineers and links code-host activity to your team. The engineer roster is the source of truth for who is on your team. DevPerform uses it to connect pull/merge request activity to named engineers. ## Handles Each engineer needs at least one username (handle) on your code host — GitHub, GitLab, or Bitbucket. This is how DevPerform matches PR/MR authors and reviewers to people on your roster. Engineers can have **multiple handles** — useful if someone uses separate personal and work accounts, has handles on more than one host, or changed their username at some point. ## Adding engineers Go to **Admin → Engineer Roster** and click **Add Engineer**. You'll need: * A display name (how they appear in the dashboard) * At least one handle * Optionally: email address (for [surveys](/surveys/overview)) and team assignment To seed your whole team at once, use **Import your team** instead of adding people one by one — see [Importing your team](/admin/import-members). Emails are filled in automatically from commit metadata (the reliable source across hosts and on private repos), and you can always edit one by hand. ## Deactivating engineers Clicking the remove button on an engineer **deactivates** them rather than deleting them. Their historical data remains in the dashboard for past date ranges, but they won't appear in current views. ## Engineers not on the roster If a PR/MR in a tracked repo is authored by someone who isn't on the roster, that engineer's data simply won't appear in the team dashboard. They're not blocked — their PRs still count for review metrics of engineers who reviewed their work. This is intentional: contractors, external contributors, or bot accounts often author PRs but shouldn't appear in team metrics. ## Multiple handles example An engineer named Alex might have: * `alex-dev` — their work account (used for all PRs in your org) * `alexsmith` — their personal account (used for open-source work that occasionally touches company repos) Adding both handles ensures both accounts' activity rolls up to Alex's row in the dashboard. ## Arrivals and idle seats DevPerform re-imports your provider org's members **daily**, so new hires appear on the People page automatically (Unassigned — free until you place them on a team). Admins see a banner when new engineers are detected. In the other direction, nobody is ever removed automatically: a team-assigned engineer with no merged activity in 60 days gets an **idle** flag on the People and Billing pages so you can decide — move them to Unassigned to stop their seat, or keep them. It's seat hygiene, not a performance signal. # Team & Engineer Metrics Source: https://docs.devperform.io/concepts/metrics The core delivery metrics on the team dashboard and how they're calculated. These are the foundational metrics on the [Team Dashboard](/dashboard/team-view), available on every plan. They're computed from your ingested pull-request data for the selected date range — a PR counts in a period if it was **merged or closed** within that window. Pull requests opened by **automation bots** (Dependabot, Renovate, and similar `[bot]` accounts) are excluded from team throughput, trends, anomaly alerts, and investment allocation — so a dependency-update storm never masquerades as team output. AI **coding agents** (Devin, Copilot coding agent, and similar) are counted: their merged work is real output, tracked separately in the [AI metrics](/metrics/ai-metrics). If a bot in your org uses a regular login (release bots, CI accounts), an admin can flag it — open the engineer's profile on the **People** page and check **Automation bot**. Flagged accounts are excluded from all analytics and never count as billable seats; the People page's **Bots** section is where you review and unflag them. Looking for DORA, phased cycle time, rework, AI, or investment metrics? Those have their own pages under **Metrics**. ## Cycle Time **Median hours from PR open to merge.** How long work takes to ship once a PR is opened. High cycle time usually means PRs are sitting in review queues or stuck in feedback loops. Displayed as hours (`4.2h`) or days (`1.3d`). For a stage-by-stage breakdown, see [phased cycle time](/metrics/flow#phased-cycle-time). ## Time to First Review **Median hours from PR open to the first reviewer engagement** — a review event *or* a reviewer comment (on GitLab and Bitbucket, review often happens in comments rather than formal approvals). Isolates the "waiting for a reviewer" portion of cycle time. High cycle time but low time-to-first-review points to the review-to-merge phase; high time-to-first-review means reviewers aren't picking work up fast enough. ## Merge Rate **Merged PRs ÷ total closed PRs.** A rate well below \~90% is worth a look — PRs may be getting abandoned, superseded, or failing checks. Shown as a percentage. ## PRs Closed Total PRs closed (merged or not) in the period. Context for activity volume, **not a target**. ## PRs Reviewed PRs the engineer participated in as a reviewer — a measure of cross-team contribution and knowledge-sharing. ## PR Comments Total review comments left, including general and inline code comments. ## Change Suggestions Reviews that requested changes. Context on review rigor, not a per-person score. ## Lines Changed Additions + deletions across merged PRs. Treat this as context for PR size, **never as a productivity measure**. ## PR Size Distribution PRs are bucketed by total lines changed (additions + deletions): | Size | Lines changed | | ---- | ------------- | | XS | under 10 | | S | 10–49 | | M | 50–249 | | L | 250–999 | | XL | 1000+ | Smaller PRs generally get reviewed faster and have lower cycle times. The distribution chart shows each engineer's size habits over the period. ## Team averages The summary cards show team **averages** (time-based metrics) or **totals** (count metrics) across all visible engineers. Changing the team filter or date range updates them instantly. # Teams Source: https://docs.devperform.io/concepts/teams How to structure your engineering org in DevPerform. Teams let you group engineers so you can filter the dashboard to a specific team and see aggregated metrics for that group. ## Hierarchy DevPerform supports up to **3 levels** of team nesting: ``` Engineering ← level 1 ├── Platform ← level 2 └── Product ← level 2 ├── Frontend ← level 3 └── Backend ← level 3 ``` A team at any level can contain engineers. There's no requirement to use all three levels — many orgs just use one flat list. ## Creating teams Go to **Admin → Teams** and click **Add Team**. You can optionally select a parent team to nest it under an existing one. Teams can be renamed at any time. Deleting a team requires its child teams to be removed first. ## Assigning engineers to teams When adding or editing an engineer in **Admin → Engineer Roster**, you can assign them to a team from a dropdown. An engineer belongs to exactly one team (or none). ## Assignment unlocks the dashboards The analytics dashboards (Team Dashboard, Executive, Delivery & Quality, Trends, Investment & Cost) unlock once at least one engineer is assigned to a team. Until then they render blurred with a prompt to finish assignment. Seats are billed on assigned engineers only — the first 5 are free — so unassigned imports never cost anything, but they also don't unlock the product. ## Filtering by team The **Team** dropdown in the dashboard header filters the entire page — summary cards, the per-engineer table, and all charts — to engineers in the selected team and any of its sub-teams. For example, selecting "Product" in the example above would show engineers from Product, Frontend, and Backend combined. # Engineer View Source: https://docs.devperform.io/dashboard/engineer-view The per-engineer detail page (a self-view, not a ranking). Clicking an engineer row in the team dashboard opens their individual detail page. It scopes the team metrics to one person and adds their recent PR history. This page is designed as a **self-view** — useful for an engineer to understand their own work and for a manager and engineer to look at together. It is not a tool for ranking people against each other; there are no peer comparisons here. ## Phased cycle time The detail page includes the engineer's own [phased cycle time](/metrics/flow#phased-cycle-time) — coding, pickup, and review stages — so they can see where their PRs tend to spend time. The deploy stage is measured at the org level. ## PR history A list of the engineer's merged PRs for the selected date range, each with: * PR title and repo * Date merged * Lines changed * Cycle time for that PR * Link to the PR/MR on your code host This makes it easy to see what drove a spike or dip in a given period. ## Navigating back The engineer view has its **own date range picker**, initialized to whatever range you were viewing on the team dashboard. Change it freely to zoom in on a sprint or out to a quarter — it only affects this page. When you go back (browser Back or the breadcrumb), the team dashboard is exactly as you left it, with its own range untouched. # Executive Summary Source: https://docs.devperform.io/dashboard/executive One org-wide view of delivery health for leadership. The **Executive Summary** is a leadership-level view that rolls up the whole organization into a single screen — less granular than the team dashboard, designed for a VP Eng or CTO who wants the headline, not the per-engineer table. ## What's on it Every tile is a headline that links to its full page: * **DORA four keys** with their Elite / High / Medium / Low bands (links to the [Delivery & Quality](/metrics/dora) page). * **Goals on track** — how many of your [working agreements](/goals) are currently met. * **Experience Index** — the latest survey composite (0–100) with its trend ([surveys](/surveys/overview)). * **AI-assisted work** — the share of merged PRs involving AI ([AI metrics](/metrics/ai-metrics)). * **Top initiatives** — the three largest initiatives by PR count, linking to the full [Investment & Cost](/metrics/investment) view. * **Share exec report** — generate a private, read-only [executive report link](/dashboard/executive-report) to send to leadership. Each card loads independently, so a hiccup in one data source doesn't blank the whole page. The full investment mix, its weekly trend, and the delivery trend live on their dedicated pages; the week-over-week anomaly callouts and AI Insights live on the [Team Dashboard](/dashboard/team-view). ## Date range Like the rest of the app, the executive view respects the date picker, so you can frame the summary to a sprint, a month, or a quarter. # Share an executive report Source: https://docs.devperform.io/dashboard/executive-report Send leadership a private, read-only summary of your delivery metrics — no login required for the reader. The **executive report** is a private, read-only web page that summarizes your team's delivery health — DORA metrics, cycle time, delivery trends, and review health — that you can share with an exec, a board member, or any stakeholder **without giving them a login**. You generate a link, choose when it expires, and send it up the chain. Whoever opens it sees a clean, at-a-glance summary. Creating a report link is available on **every plan, including Free**. The sections inside the report follow your plan — a Free report shows the core delivery metrics; the investment-mix headline needs **Growth**, and the AI-impact headline needs **Pro**. ## Create a report link 1. Open the **Executive Summary** dashboard. 2. Click **Share exec report** (visible to account owners and admins). 3. Choose how long the link stays valid — **7, 30, or 90 days** — and add an optional label (e.g. "For our CTO" or "Q3 board deck"). 4. Optionally tick **Include cost figures in the link** and enter your engineering cost for the report window and/or monthly AI tooling spend to add a dollar view (see below). The amounts prefill from the values you've entered on Investment & Cost and AI ROI, but are only added to the link when you explicitly tick the box. 5. Click **Create link**, then **Copy**. The link is shown **once**. Copy it before closing the dialog — for security DevPerform never stores the link itself and can't show it again. If you lose it, just create a new one. ## What the report shows The report is computed **live** each time it's opened, over a trailing 90-day window (trend series cover the matching 13 weeks): * **Delivery (DORA)** — deployment frequency, lead time, change failure rate, and time to restore, each with an Elite / High / Medium / Low band. * **Cycle time by phase** — median time from first commit to PR open, in pickup, and in review. (The first stage is labeled exactly what it measures — in commit-then-open workflows, AI agents especially, the observable gap between first commit and PR open is small, and that's real, not a bug.) * **Delivery trend** — PRs merged and cycle time, week by week. * **Review health** — merged PR volume, time to first review, and the share of PRs merged without review. * **Investment mix** *(Growth and Pro)* — how effort splits across features, maintenance, and keep-the-lights-on. * **Engineering cost** *(Growth and Pro, shown first — it's what leadership reads first)* — the capitalizable-vs-expensed effort split (the ASC 350-40 view finance teams use). Shown as percentages by default; if you entered cost figures when creating the link, the reader also sees the dollar split and your monthly AI tooling cost (with an approximate cost per AI-assisted PR on Pro). * **AI-assisted work** *(Pro)* — the share of merged PRs with AI-authored commits. **Your cost basis never reaches our servers.** Like everywhere else in DevPerform, compensation figures stay in your browser: the basis you enter travels only **inside the link itself** (in the part of the URL browsers never send to servers), and the reader's browser does the dollar math locally. Anyone holding the link can see the amount, so share it accordingly. **The report only ever shows team and organization-level aggregates.** It never includes individual engineer names, per-person metrics, or any survey answers — it's a health view, not a ranking. This is the same data-honesty boundary the rest of DevPerform holds to. ## Manage and revoke links Reopen the **Share exec report** dialog to see your active links — each with its label, expiry, and view count — and **revoke** any of them instantly. Links also stop working automatically at their expiry date. A reader who opens an expired or revoked link sees a friendly "this report link has expired" page, never an error. # Filters & Date Range Source: https://docs.devperform.io/dashboard/filters How to scope the dashboard to what you care about. ## Date range The date picker in the top-right of the dashboard controls the window for all metrics. You can: * Pick preset ranges: Last 7 days, Last 30 days, Last 90 days, or YTD (January 1 of the current year through today) * Enter a custom start and end date The range is **inclusive** on both ends — PRs merged on the start date and end date are both included. Today's date is always included in the "last N days" presets. ## Team filter The team dropdown to the left of the date picker scopes the dashboard to a specific team. Selecting a team includes: * Engineers directly in that team * Engineers in any sub-team (descendants at all levels) Selecting **All Teams** (the default) shows your full roster. The team filter affects summary cards, the per-engineer table, and all charts simultaneously. ## Name search The search box inside the per-engineer table filters the visible rows by engineer name. This is a local filter — it doesn't affect the summary cards, which always reflect the full team filter and date range. ## Combining filters You can combine the team filter, date range, and name search freely. A common workflow: 1. Set a monthly date range 2. Filter to a specific team 3. Use the table sort to find outliers 4. Click through to the engineer view for context # Team Dashboard Source: https://docs.devperform.io/dashboard/team-view Understanding the team-level metrics view. The Team Dashboard is the main day-to-day view in DevPerform. It shows aggregated and per-engineer metrics for your entire roster (or a filtered team) over a selected date range. ## Summary cards The cards at the top give a quick snapshot of the period: * **PRs Closed** — total PRs closed across all visible engineers * **Avg Cycle Time** — median cycle time averaged across engineers * **Review Turnaround** — median time-to-first-review averaged across engineers * **PRs Reviewed** — total review participation * **Avg Merge Rate** — average merge rate across engineers * **Unreviewed Merges** — how many merged PRs shipped with zero reviews (and the % of merges) * **Review Depth** — median comments per merged PR The last two are [review-health](/metrics/flow#review-health) signals. All cards update instantly when you change the date range or team filter. ## Investment mix The investment mix, its weekly trend, and effort-by-initiative live together on the **[Investment & Cost](/metrics/investment)** page (Business section of the sidebar), scoped by the same team filter. ## Per-engineer table The table below breaks down every metric by engineer. Click any column header to sort. Click any engineer row to drill into their [individual view](/dashboard/engineer-view). Use the search box to filter the table by name without changing the summary cards. A 🔥 **overload flag** appears next to any engineer whose open-PR count exceeds your org's burnout threshold — a protective signal that someone may be juggling too much, not a performance mark. ## Charts Four charts visualize the team breakdown: * **PRs Closed vs Reviewed** — who's authoring vs reviewing * **Cycle Time & First Review** — time-based comparison across engineers * **Lines Changed** — change volume by engineer (context for PR size, not a score) * **PR Size Distribution** — stacked bar showing each engineer's size habits Charts always reflect the team filter and date range, same as the summary cards. DevPerform intentionally does **not** rank engineers against each other — there are no "fastest" or "most output" leaderboards. Per-person data exists for an engineer's own self-view and for protective signals like the overload flag. See our [team-health stance](/introduction#a-team-health-tool-not-a-ranking-tool). # Trends Source: https://docs.devperform.io/dashboard/trends Weekly delivery, review-health, and CI trends — with anomalous weeks flagged. The Trends page shows how your team's delivery is moving week by week (UTC weeks, Monday-start), over the last 8–52 weeks, for all teams or a single team. ## Charts * **Throughput** — PRs opened vs merged per week. Weeks the anomaly detector flags (±25% vs the trailing month, the same rule that drives Slack/Teams alerts) are highlighted in red. * **Speed** — median cycle time (open → merge) alongside median **time to first review**, so you can see whether slowdowns come from review pickup or from the review-to-merge phase. * **Review health** — the share of PRs merged with **no review**, and the **top reviewer's share** of all review activity. A rising top-reviewer line means review load is concentrating on one person. * **People & batch size** — distinct contributors merging each week, next to median PR size. Growing PR sizes are the most common silent driver of rising cycle time. * **Work in progress** — how many PRs were open at each week's end, and their median age. A climbing line means work is starting faster than it's finishing. * **CI health** — pipeline success rate and median duration per week (shown once CI runs are ingested; repo-wide, not filtered by team). ## Notes * The right-most point is the **current, in-progress week** — expect it to look low until the week completes. Anomaly flagging skips it. * PRs from automation bots (Dependabot, Renovate, and similar) are excluded; AI coding agents' work is included. # GitHub Org Setup Source: https://docs.devperform.io/github-org-setup How to authorize DevPerform to access your GitHub organization's repositories. GitHub requires org admins to explicitly approve third-party OAuth apps before they can access private org repos. This is a one-time step per organization. ## Why this is needed When you sign in with GitHub, DevPerform receives an OAuth token scoped to your personal account. That token can read your public repos immediately, but **private repos inside a GitHub org are blocked by default** until an org admin grants access. ## Option A — Approve during sign-in (easiest) When you click **Sign in with GitHub** and GitHub shows the authorization screen, you'll see a section listing your organizations. Click **Grant** next to the org you want to connect. If you're not an org admin, you can click **Request** instead — this sends an approval request to your org admin. If you skip this step, you can come back and grant access later from your GitHub settings. ## Option B — Approve from GitHub org settings If you already signed in without granting org access: 1. Go to **GitHub → Settings → Applications → Authorized OAuth Apps** 2. Find **DevPerform** in the list and click it 3. Under **Organization access**, click **Grant** next to your org Or as an org admin: 1. Go to your **GitHub org → Settings → Third-party Access → OAuth app policy** 2. Find **DevPerform** and click **Grant access** ## Repository access selection (GitHub App installs) If you connected by **installing the DevPerform GitHub App** on your org (the guided "Connect GitHub" flow), GitHub asks which repositories the app may access: * **All repositories** — recommended; new repos are picked up automatically. * **Only select repositories** — fine too, but make sure you actually select at least one. If the installation ends up with **no repositories granted** (nothing selected, or an org admin later trims the app's access), DevPerform can't see any code activity and your dashboard shows a banner instead of data. To fix it: 1. On GitHub, go to **your org → Settings → GitHub Apps → DevPerform → Configure** and grant access to the repositories you want tracked. 2. Back in DevPerform, click **Re-check repositories** on the banner (or wait a moment — access changes sync automatically). Newly granted repos are tracked and their history backfills in the background. ## Verifying access Once access is granted, go back to DevPerform Admin and add a repo from that org. If it loads metrics without an error, the token has the right access. If you see a GitHub API error about resource not accessible, the org authorization step hasn't completed yet. ## Private vs public repos Public repos in your org do not require org approval — they're accessible with any GitHub token. Only private repos require the org approval step above. # GitLab Setup Source: https://docs.devperform.io/gitlab-setup Connect a GitLab group or project — gitlab.com or self-hosted. DevPerform reads merge requests, approvals, and commits from GitLab to compute the same metrics it does for GitHub. ## Connect GitLab 1. Sign in to DevPerform (with GitLab, or any provider). 2. In **Admin → Connect a code host**, click **Connect GitLab**. 3. Authorize DevPerform on the GitLab consent screen. It requests **read-only** access (`read_api`, `read_user`) — enough to read merge requests, projects, and members; it never writes to your code. 4. DevPerform creates your GitLab workspace, auto-tracks the projects you can access, and starts syncing immediately. Connecting GitLab also signs you in — a GitLab-only team never needs a GitHub account. ## Self-hosted GitLab Self-hosted instances (behind your own SSO) are supported. When connecting, expand **Self-hosted?** and enter your instance URL (e.g. `https://gitlab.your-company.com`). Your instance enforces its own SSO during authorization. Self-hosted instances need a one-time OAuth application registered on your GitLab. [Contact us](mailto:sales@devperform.io) and we'll walk your admin through it. ## What gets read * Merge requests + approvals, comments, commits, and diffs (cycle time, review health, churn) * Project deployments and labeled issues (for DORA — optional) * Group / project members (for the one-click team import) Read-only throughout. DevPerform never pushes code, comments, or status checks. # Goals & Working Agreements Source: https://docs.devperform.io/goals Set measurable team targets and track progress against them. Goals (sometimes called "working agreements") let a team commit to a measurable target tied to any DevPerform metric, and track whether they're meeting it. ## Examples * Keep median **PR size under 100 lines** * Keep **cycle time under 2 days** * Keep **unreviewed merges under 5%** ## How they work 1. Create a goal against a metric, with a target threshold and direction (under / over). 2. DevPerform evaluates it for the selected period and marks it **met** or **not met**. 3. The [executive summary](/dashboard/executive) shows an at-a-glance "**N of M goals on track**" rollup. Goals are framed as shared team agreements, not individual quotas — consistent with DevPerform's team-health positioning. They're a way for a team to hold *itself* accountable to the working norms it chose. Goals are available on the **Growth** plan and up. See [Plans](/plans). ## Survey-dimension goals Goals can target survey dimensions as well as delivery metrics: pick any dimension from your surveys (unit /100, higher is better) and the goal evaluates against the newest survey wave that clears the anonymity threshold — waves below it show "no data" rather than a pass/fail. The fastest way to create one is from a survey's results: mark a dimension as a Focus area and use "Create a goal from this." # How DevPerform Works Source: https://docs.devperform.io/how-it-works Where your data comes from, what's stored, and how often it refreshes. DevPerform is a **data pipeline plus an analytics layer**. Instead of calling your code host's API every time you open a dashboard, it ingests your delivery data into its own database and computes metrics from that store. That's what makes dashboards fast and lets history accumulate for trends. It works the same across **GitHub, GitLab, and Bitbucket** — a provider abstraction normalizes each host's data into one shape. ## The pipeline ``` GitHub / GitLab ──(sync: hourly + on repo-add)──► DevPerform database ──► metrics ──► dashboards / Bitbucket pull/merge requests, reviews, (fast queries, comments, commits, files, history retained) deploys, incidents ``` * **Ingestion** pulls PRs/MRs with their reviews, comments, commits, and per-file line counts (GitHub via GraphQL + a REST fallback; GitLab via REST v4; Bitbucket via REST 2.0) — all normalized into the same shape. * **Sync runs hourly** and immediately when you add a repo, so new PRs show up without you doing anything. * For the Pro **rework** metric, DevPerform additionally fetches recent commit diffs over a rolling \~21-day window to measure how much code is rewritten. Only the aggregate churn numbers are kept. ## What's stored — and what isn't PR titles, authors, timestamps, review/comment events, merge state, file paths, and additions/deletions counts — plus the metrics computed from them. Your source code. Commit diffs are fetched transiently to compute rework and are not retained as source. ## Connecting your code host You sign in with **GitHub, GitLab, or Bitbucket** — and the same connection lets DevPerform read your delivery data. Setup is per-host: see [GitHub Org Setup](/github-org-setup), [GitLab Setup](/gitlab-setup), or [Bitbucket Setup](/bitbucket-setup). For GitHub, DevPerform can also operate as a **GitHub App** installed on your org — scoped, server-to-server access tokens that scale to larger orgs instead of relying on one person's OAuth token. GitLab and Bitbucket connect via OAuth (the org stores an encrypted, auto-refreshed token). If you're evaluating DevPerform for a bigger organization, ask us about the options. ## Multi-tenant by design Every piece of data is scoped to your organization. Metrics queries always filter by your org, so one customer's data is never visible to another. ## Freshness Because metrics come from the synced store, a brand-new PR appears at the next sync (within the hour, or immediately when you add its repo). If you've just connected a repo, give the first sync a minute to backfill history before the dashboards fill in. # Incident tools Source: https://docs.devperform.io/integrations/incident-tools Connect PagerDuty so DORA change-failure-rate and time-to-restore use real incidents. Connect your incident tool so DevPerform's **DORA change-failure-rate** and **time-to-restore (MTTR)** are based on **real incidents** — instead of the fallback heuristic of counting issues labeled `incident` in your repos. DevPerform supports **PagerDuty** today (Datadog and Opsgenie are on the roadmap). The connection is **account-wide** and admin-only, and uses a **read-only API token** — no OAuth app to register. ## Connect PagerDuty 1. In PagerDuty, create a **read-only** REST API key: **Integrations → API Access Keys → Create New API Key**, tick **Read-only**, and copy it. 2. In DevPerform, go to **Admin → Connections → Incident tool**. 3. Paste the token and click **Connect PagerDuty**. DevPerform verifies it and starts syncing your incidents. Use **Sync now** any time to pull the latest, or **Disconnect** to stop. ## What it changes * **Change-failure-rate** — incidents ÷ deployments in the window, using your real PagerDuty incidents. * **Time-to-restore (MTTR)** — median time from a PagerDuty incident's creation to its resolution. Both flow into your existing **DORA dashboard** automatically, counted at the **account level** (across all your connected orgs). Until an incident tool is connected, DevPerform falls back to counting issues labeled `incident` in your repos. PagerDuty is the more accurate source, so connecting it is recommended if you use it. # Issue trackers Source: https://docs.devperform.io/integrations/issue-trackers Connect Jira, Linear, or Azure DevOps Boards to map issues to pull requests — real effort allocation by initiative and planning analytics. Connect your issue tracker to DevPerform to link **issues to the pull requests that deliver them**. That unlocks **Investment by Initiative** (where did our engineering effort actually go, by epic or project?) plus issue-level cycle time and planning views — grounded in real ticket → PR mapping, not guesswork. DevPerform supports **Jira**, **Linear**, and **Azure DevOps Boards**. The connection is **account-wide** (one tracker per company) and admin-only. Access is **read-only** — DevPerform never changes your tracker's data. ## Connect 1. Go to **Admin → Connections → Issue tracker**. 2. Click **Connect Jira**, **Connect Linear**, or **Connect Azure DevOps**. 3. Approve the requested read access on your tracker. 4. You'll return to Admin with the tracker connected. DevPerform immediately syncs your issues and links them to your pull requests. Use **Sync now** any time to pull the latest and re-link. ## How issue ↔ PR linking works DevPerform links a pull request to an issue when the issue's **key** appears in the PR's **branch name, title, or description**: * **Jira / Linear** — the issue key, e.g. `PROJ-123` or `ENG-42`. * **Azure DevOps** — the Boards reference `AB#123` (a bare `#123` is ignored, since it collides with GitHub PR/issue numbers). Most teams already do this — a branch named `feature/ENG-42-…` or `AB#123` in the PR description is enough. Linear and Azure DevOps can generate a matching branch name straight from the work item. ## What you get * **Investment by Initiative** — merged-PR effort rolled up to the **epic** (Jira / Azure DevOps) or **project** (Linear) it belongs to, so you can see how effort splits across the roadmap. * **Planning & delivery** — issue status, story points, and cycle time alongside your delivery metrics. ## Per-tracker notes ### Jira Works with **Jira Cloud**. On connect you'll choose the Atlassian site to authorize; DevPerform reads issues, projects, and fields. ### Linear Linear has no epics, so an issue rolls up to its **Project** as the initiative. Connect authorizes read access to your workspace. ### Azure DevOps Boards Azure DevOps authenticates through **Microsoft Entra ID**. If your organization restricts third-party apps, an org admin may need to enable **Organization settings → Policies → "Third-party application access via OAuth"** before the connect will succeed. Work items roll up **Epic → Feature → Story → Task** to the top-level epic. # Microsoft Teams Source: https://docs.devperform.io/integrations/microsoft-teams Post the weekly team-health digest to a Microsoft Teams channel via a webhook. Connect a Microsoft Teams channel to receive DevPerform's **weekly team-health digest** — the same content as the [Slack digest](/integrations/slack), delivered to the channel of your choice. It's optional, admin-only, and takes about a minute to set up. Unlike Slack, Teams delivery is **webhook-based** — there's no app to install and no admin consent needed. You create a webhook on the channel and paste the URL into DevPerform. ## 1. Create a channel webhook In Microsoft Teams, use the built-in **Workflows** app to create an incoming webhook: 1. Next to the channel name, click **⋯ (More options) → Workflows** (or open the **Workflows** app). 2. In the template search box, type **`webhook`** and choose **"Send webhook alerts to a channel."** 3. Confirm the connection, pick the **team** and **channel** you want, and click **Add workflow**. 4. **Copy the workflow's URL** — that's your webhook. (Paste it into DevPerform in the next step.) Pick **"Send webhook alerts to a channel"** — *not* the "from specific people" or "from people in an org" variants. Those add a sender allowlist, and since DevPerform posts from outside your organization, they will block its messages. Also avoid the "…to a chat" template — you want a **channel**. Microsoft renamed this template (it was formerly "Post to a channel when a webhook request is received") and replaced the older "Incoming Webhook" connector with **Workflows**. If you close the dialog before copying the URL, get it back via the channel's **⋯ → Workflows → your workflow → edit** (the trigger step shows the URL), or from **[make.powerautomate.com](https://make.powerautomate.com) → My flows**. ## 2. Connect it in DevPerform 1. Go to **Admin → Connections → Microsoft Teams**. 2. Paste the **webhook URL** (and an optional label, e.g. `#engineering`). 3. Click **Connect Teams**. DevPerform posts a confirmation card to the channel — if you see it, you're set. For security, DevPerform only accepts webhook URLs on Microsoft's domains (`webhook.office.com`, `logic.azure.com`, or `powerplatform.com`) — every URL Teams or Power Automate generates qualifies. If yours is rejected, copy it again from the workflow's trigger step rather than a proxy or shortened link. ## What you get * **Weekly team-health digest** — every Monday, a card with last week's delivery headline (PRs opened/merged, median cycle time), current open-PR count, notable week-over-week changes, and (if enabled) AI highlights. * **Stale-PR nudges** — a periodic card listing open PRs that are getting old or still need a review, so nothing slips. * **Anomaly alerts** — a heads-up when a delivery metric regresses week-over-week (deduped to at most once per week). * **Send digest now / Send test** — preview any time from the Admin panel. * **Per-feature toggles** — turn the weekly digest, nudges, or anomaly alerts on/off independently, without disconnecting. Per-person **survey DMs** over Teams are on the roadmap (they require a Teams bot, unlike the channel posts above). ## Managing the connection Everything lives under **Admin → Connections → Microsoft Teams**: send a test, send the digest immediately, toggle the weekly schedule, or **Disconnect**. Only account admins can manage it. To change channels, create a new webhook and reconnect. ### If posts stop arriving Teams webhooks can be deleted or rotated on the Teams side (for example when the Workflows flow is removed or the channel is archived). When that happens, DevPerform detects the failing webhook and the Connections card shows an amber **"Teams webhook is failing"** state with a field to paste a fresh webhook URL — create a new webhook (step 1 above) and reconnect. Digests, nudges, and alerts resume immediately. # Slack Source: https://docs.devperform.io/integrations/slack Connect Slack to get a weekly team-health digest and deliver surveys over Slack DM. Connect a Slack workspace to DevPerform to receive a **weekly team-health digest** in a channel of your choice, and to **deliver surveys over Slack DM** instead of (or alongside) email. It's optional, admin-only, and you can disconnect at any time. ## Connect your workspace 1. Go to **Admin → Slack**. 2. Click **Add to Slack** and approve the requested permissions in Slack. 3. You'll land back on the Admin page with Slack connected. Each DevPerform account connects a single Slack workspace. Only account admins can connect, disconnect, or change Slack settings. ## Weekly team-health digest Once connected, pick a **channel** under Admin → Slack. Every **Monday morning** DevPerform posts a short digest there: * Last week's delivery headline — PRs merged and median cycle time. * Any notable **week-over-week changes** (e.g. "Cycle time ↑ 40% vs the prior weeks"), so regressions surface without anyone opening a dashboard. Use **Send digest now** to preview it immediately instead of waiting for Monday. ## Deliver surveys over Slack When you send a survey, choose how it goes out under **Deliver via**: * **Email** — the default. * **Slack DM** — DevPerform matches each recipient to their Slack account by email and sends the survey link as a direct message. Anyone not in the workspace (or whose Slack email doesn't match) automatically **falls back to email**, so no one is missed. * **Both** — email and Slack DM. Reminders follow the same channel the survey was sent on. Responses stay **anonymous** exactly as they do over email — a Slack DM is one-to-one, and individual answers are never attributed. Survey delivery over Slack matches people by their email address, so an engineer must have an email on file in DevPerform and be in the connected Slack workspace with that same address. Otherwise they receive the survey by email. ## Personal PR notifications (opt-in) Beyond the team digest, each engineer can opt in to **Slack DMs about their own pull requests** under **Settings → Personal notifications**. Pick which events you want: * **PR approved** / **Changes requested** — a reviewer acted on your PR. * **Review requested** — someone asked you to review their PR. * **PR merged** — your PR was merged by someone else. * **CI failed** / **CI passed** — a CI run on your PR finished (CI passed is off by default; it can be chatty). Three things to know: * **Self-only, always.** Notifications go to the person the PR belongs to — never to a manager, never to a channel, never aggregated. There is no admin view of anyone's notification activity. * **Off by default.** Nobody gets DMs until they turn them on themselves, and there's a **Send test DM** button to confirm delivery. * **Delivery timing depends on your code host** (see below). DMs find you by email, so your DevPerform email must match your Slack account's email. ### GitHub and GitLab * **GitHub** — near-real-time, driven by webhooks: DMs arrive within moments of the event. * **GitLab** — GitLab connections are OAuth-based with no webhook path, so DevPerform spots your events at **sync time**: DMs go out when DevPerform next syncs your projects (on the regular sync cadence) rather than instantly, making them near-real-time rather than immediate. Because events are detected by comparing each sync rather than receiving a one-shot webhook, a **shared dedup ledger** records what's already been sent — so a re-sync never DMs you twice about the same event. GitLab covers **PR approved**, **PR merged**, and **CI passed / failed**; **Review requested** and **Changes requested** aren't available from GitLab's OAuth API and so aren't sent for GitLab merge requests. * **Bitbucket** — personal notifications aren't available yet. Requires a connected Slack workspace on a plan that includes Slack features. ## Permissions DevPerform requests only what it needs: post messages, list channels for the digest picker, and look up users by email for survey delivery. It never reads your messages. ## Disconnect Go to **Admin → Slack → Disconnect**. DevPerform forgets the workspace token immediately; digests and Slack survey delivery stop (surveys fall back to email). # Introduction Source: https://docs.devperform.io/introduction Engineering intelligence built for teams that care about flow and health, not surveillance. DevPerform connects to your code host — **GitHub, GitLab, or Bitbucket** — and turns your delivery data into the metrics engineering leaders actually need: how work flows, where it stalls, how healthy the team is, and — increasingly — how AI is changing the way code gets written. Everything works the same whichever of the three your team uses. ## What DevPerform gives you DORA's four keys, phased cycle time, review health, and weekly trends. Line-level rework/churn and the files that change the most. Human vs. AI-assisted vs. agent-authored work, acceptance, and rework on AI code. DX and engagement surveys, driver analysis, goals, and an executive summary. ## A team-health tool, not a ranking tool DevPerform measures **teams and systems**. Individual data is shown only as a person's own self-view or as a protective health signal (like a burnout flag) — never as a ranked "who's fastest" scoreboard. We don't treat lines of code or PR counts as productivity scores, and we don't track keystrokes or individual activity. This is a deliberate stance: gamifying individual output metrics backfires, and in the AI era raw line counts mean even less. ## How it works, briefly 1. Sign in with **GitHub, GitLab, or Bitbucket**, then connect the org / group / workspace and add the repos to track. 2. Engineers are added to a roster (manually or imported from your org / group / workspace in one click). 3. DevPerform **syncs your PR/MR, review, and commit metadata into its own database** — hourly and on demand — so dashboards are fast and history builds up over time. 4. Metrics are computed from that store and shown per team, per engineer, and org-wide. Use a different code host (e.g. Azure DevOps)? [Contact sales](mailto:sales@devperform.io) — we add providers based on demand. DevPerform stores delivery **metadata** (PR titles, authors, timestamps, review events, file paths, line counts) and computed aggregates — **not your source code**. See [How DevPerform works](/how-it-works) for the full picture. Some metrics (rework/churn, AI-native metrics) are part of the **Pro** plan. Each metric page notes its plan. See [Plans](/plans). # AI-Native Metrics Source: https://docs.devperform.io/metrics/ai-metrics Measure how AI coding tools are changing how your team ships. AI-native metrics are part of the **Pro** plan. See [Plans](/plans). As teams adopt coding agents (Claude Code, Cursor, Copilot, and others), the important questions change: how much work is AI-assisted, does AI-written code get accepted and stay, and does it shift the review burden? DevPerform measures all of this from your existing code-host data (GitHub, GitLab, or Bitbucket) — no IDE plugin required. ## How authorship is detected DevPerform reads commit metadata — message trailers ("Co-authored-by", "Generated with" lines) plus the git author identity that cloud agents commit under — to attribute work to a tool: **Claude Code, Cursor, GitHub Copilot (coding agent, VS Code, CLI), Devin, Aider, OpenAI Codex, Windsurf, Google Jules, Gemini Code Assist, OpenHands, Amp, Amazon Q, Kiro, JetBrains Junie, Replit Agent, Factory Droid, and Ona**. Each PR is then classified three ways: | Class | Meaning | | ------------ | -------------------------------------------------------------------------- | | **Human** | No AI attribution detected | | **Assisted** | A person authored, with AI help signals present | | **Agent** | Authored by an autonomous agent identity (e.g. Devin, Copilot's SWE agent) | These numbers are a **lower bound**. AI use that leaves no trace in commit metadata is invisible to detection, so real AI involvement is at least what's reported, often more. DevPerform states this honestly rather than overclaiming. ## The metrics Share of merged PRs and commits attributed to AI, broken down by tool and by human / assisted / agent. How often AI-attributed PRs get merged vs. closed unmerged, compared to human PRs. Whether AI-written lines get rewritten more or less than human-written lines (built on the rework engine). Comments per PR, time-to-first-review, and reviewed rate for AI vs. human work — does AI move the bottleneck to review? How often AI-authored commits get reverted compared to human commits — a signal of whether AI code stays once it ships. Most of these also expose a human / assisted / agent split, since agent-authored work is usually the sharpest cohort to watch. ## How the data fills in AI attribution is stamped as commits are synced, so the numbers **backfill gradually** — only re-synced commits carry authorship. Expect coverage to improve over the first sync cycles after enabling Pro. ## AI Impact views The **AI Impact** page (Pro) adds two team-level analyses: * **Adoption cohorts** — with four or more teams, DevPerform splits them into higher- and lower-AI-adoption cohorts at the median and compares cycle time, throughput per contributor, unreviewed-merge rate, and revert rate. Below four teams you get honest per-team rows instead of a forced split. * **Adoption vs delivery trends** — weekly AI-authored PR share charted against cycle time, throughput, and revert rate, so "did delivery change as AI ramped?" is answerable at a glance. Both views measure adoption from AI-attributed commits (a lower bound) and carry a correlation-is-not-causation note, plus an **industry context line** citing openly published adoption figures (Stack Overflow's 2025 developer survey and Google's DORA 2025 report, linked on the page) so your adoption number has a reference point. **DevPerform never tracks individual AI usage** — the smallest unit in any AI metric is a team. ## AI Tools comparison The **AI Tools** page (Pro) compares detected AI tools side by side: attributed PRs, commits and lines, revert and unreviewed-merge rates per tool, and a weekly adoption chart. Enter each tool's monthly spend (kept in your browser — never stored server-side) to get **cost per AI-assisted PR by tool** and a spend-share vs work-share comparison. Detection is commit-signature based — message trailers plus the git author identity that cloud agents commit under — a lower bound whose coverage varies by tool; the page says so. It also shows **seat utilization**: how many people actively used each tool in the period — as a **count only, never a list of names** — and, if you enter how many seats you pay for (also browser-only), the idle-seat count and the spend tied up in them. "You pay for 20 Copilot seats and 8 were active this month" is often the fastest AI-cost win there is. # AI ROI Report Source: https://docs.devperform.io/metrics/ai-roi Survey-reported time savings fused with AI-authorship telemetry — the exec-facing AI ROI number, computed honestly. The AI ROI report (Pro, admin-only) answers the question every engineering leader gets asked: **"what are we actually getting from AI coding tools?"** It fuses two sources you already have in DevPerform: 1. **What your engineers report** — three survey questions from the AI impact set: weekly time saved by AI tools, confidence in AI-generated code quality, and the share of work that's substantially agent-written. Responses aggregate at team level with the same anonymity suppression as every other survey result. 2. **What the code shows** — AI-authored share of merged PRs and AI-vs-human rework, from commit-trailer detection on your git history. No agents or daemons on developer machines. ## The math, transparently * Estimated savings = **median** reported hours saved per week × active contributors × a loaded hourly cost you enter (median, so one enthusiastic answer can't inflate the number; the top "16h+" bucket is deliberately capped at 20h — half a work week — in the math. Surveys sent on the older 5-bucket scale keep their original 10h cap). * Your hourly-cost and AI-spend inputs live only in your browser — DevPerform never stores compensation data. * Entering monthly AI spend adds a net-ROI line and cost per AI-assisted PR. * Telemetry is shown **alongside** the self-reported figure, never multiplied into it — self-reports are perception data, telemetry is a lower bound, and the report says so on the page. ## What published research says The report includes a collapsible summary of peer-reviewed and published studies on AI coding productivity — results genuinely range from **negative** (a 2025 randomized trial with experienced open-source maintainers found tasks took 19% *longer* with AI) to **strongly positive** (a 2023 controlled experiment measured 55.8% faster completion on a scoped task), with large field experiments landing in between (+26% across \~4,900 developers). Each study is linked with its scope caveats. That spread is exactly why the report leads with what *your* engineers report, corroborated by *your* git telemetry, instead of applying a universal multiplier. Some tools compute AI ROI by tracking individual developers before and after AI adoption. DevPerform doesn't — adoption and impact are measured for teams only, by design. See the [AI Impact views](/metrics/ai-metrics) for team-level cohort and trend analysis. # The Free Benchmark Source: https://docs.devperform.io/metrics/benchmark How the public repo benchmark works, what it measures, and where the industry bands come from. The [free benchmark](https://devperform.io/benchmark) scores any **public GitHub repo** in seconds — no signup, no installation. Paste a repo, get a scorecard. It's the fastest way to see the kind of analysis DevPerform runs continuously on your own private repos. ## What it measures Computed from the repo's recently merged pull requests (public data only — we read PR metadata, never your code): | Metric | What it is | | ------------------------ | ----------------------------------------------------------------------------------- | | **Cycle time** | Median hours from PR opened to merged | | **Time to first review** | Median hours from PR opened to the first non-author review or comment (pickup time) | | **PR size** | Median lines changed per merged PR | | **Throughput** | Merged PRs per week | ## Where the bands come from Each metric is labeled **Elite / High / Medium / Low** against published industry data — not numbers we invented: * **Cycle time, time to first review, and PR size** tiers follow [LinearB's community benchmarks](https://linearb.helpdocs.io/article/d2v8kqzxzd-metrics-community-benchmarks), published from their 2026 dataset of 8.1M+ pull requests across 4,813 teams. * The [DORA dashboard](/metrics/dora) inside the product uses the canonical DORA State of DevOps thresholds. One methodological note, disclosed on purpose: the published tiers aggregate team values at the 75th percentile, while the benchmark bands your repo's **median** — a slightly generous comparison for repos with occasional very slow PRs. Bands are directional reference points, not a verdict. ## Sharing a scorecard Every result has a shareable link that unfurls as a scorecard card in Slack, LinkedIn, or X — paste `devperform.io/api/public/benchmark/share//` anywhere links unfurl. ## Monthly tracking Leaving your email on a scorecard subscribes you to that repo's numbers: today's report arrives right away, and a fresh scorecard lands about monthly with the change since last time (for example, "cycle time 9.2h, was 12.0h"). One email a month per tracked repo, nothing else. Every tracking email carries a one-click unsubscribe link, and unsubscribing is permanent unless you deliberately re-submit the form. ## Privacy The benchmark reads public PR metadata via the GitHub API. Leaving an email is optional — it subscribes you to the monthly scorecard for that repo (see above), and nothing else. No other mail, no list-sharing, unsubscribe anytime. # CI/CD Analytics Source: https://docs.devperform.io/metrics/cicd Pipeline health — success rate, duration, and flaky-run/flaky-test detection across GitHub, GitLab, and Bitbucket. DevPerform ingests your CI/CD pipeline runs and turns them into health metrics, shown alongside your delivery data. It works with **GitHub Actions**, **GitLab pipelines**, and **Bitbucket Pipelines** — no setup beyond connecting your code host. ## Pipeline health For the selected window — overall and **broken down by workflow/pipeline**: * **Run volume** — how many pipeline runs completed. * **Success rate** — the percentage that succeeded. * **Duration** — median and p90 wall-clock time, so slow pipelines stand out. ## Flaky runs A **flaky run** is one that failed and then **passed on a re-run of the same commit** — a strong signal of nondeterministic tests or flaky infrastructure. DevPerform surfaces a **flaky rate** so you can quantify how much re-running your team does. Flaky-run detection relies on CI re-run attempts, which **GitHub Actions** exposes. GitLab and Bitbucket don't report attempt numbers, so they show 0% flaky. ## Flaky tests Beyond whole runs, DevPerform pinpoints the **individual tests** that are flaky — a test that **failed in a run whose pipeline also passed on the same commit**. They're ranked so you can fix the worst offenders first. Flaky-test detection reads your **JUnit XML test reports**. To turn it on, have your CI upload its JUnit results as a build artifact (for example, a GitHub Actions `upload-artifact` step for your `junit.xml`). The panel stays hidden until there's data. ## Where to find it CI/CD metrics appear on the **delivery dashboard**, next to your DORA keys. # Code Quality — Rework & Hotspots Source: https://docs.devperform.io/metrics/code-quality Line-level rework/churn and the files that change the most. Rework and hotspots are part of the **Pro** plan. See [Plans](/plans). These metrics look past delivery speed at the *stability* of the code being shipped. ## Rework / churn **Rework** is the percentage of recently-written lines that get rewritten again within a short window (\~21 days). It's the GitClear-style "code churn" signal: high rework means code is thrashing — written, then quickly rewritten — which often indicates unclear requirements, rushed work, or design churn. How DevPerform measures it: * It tracks each line's lifetime across commits (when a line was introduced and when it was overwritten). * **Generated, vendored, and lock files are excluded** (e.g. bundles, `package-lock.json`) so they don't inflate the number. * The result is shown as a rate with a health band (healthy / elevated / high). A healthy baseline is typically in the low-to-mid teens (%). Persistently high rework on a team or repo is worth a conversation about scope and review. ## Churn hotspots **Hotspots** rank the files that change the most across merged PRs — by number of changes, additions, deletions, and how many PRs touched them. They point you to the parts of the codebase that absorb the most ongoing effort, which are good candidates for refactoring, better test coverage, or clearer ownership. ## Why this pairs with AI Rework is also the foundation for the AI-native [rework-on-AI-code](/metrics/ai-metrics) metric: because DevPerform knows each line's authorship, it can compare whether AI-written code churns more or less than human-written code. # DORA Metrics Source: https://docs.devperform.io/metrics/dora The four DORA keys, how DevPerform derives them, and how the bands work. DORA (DevOps Research and Assessment) defines four widely-used measures of software delivery performance. DevPerform computes all four from your ingested data and shows them at the top of the **Delivery & Quality** page ("DORA — the four keys") with Elite / High / Medium / Low bands — the same page also covers cycle-time phases, CI/CD health, flaky tests, code rework, and issue-tracker planning. ## The four keys | Metric | What it measures | How DevPerform derives it | | ------------------------- | ----------------------------------- | ------------------------------------------------------------------- | | **Deployment Frequency** | How often you ship | Merged pull requests, or successful runs of a named deploy workflow | | **Lead Time for Changes** | How long from work to production | Median PR open→merge (merges mode) or merge→deploy (actions mode) | | **Change Failure Rate** | How often a change causes a failure | Incidents ÷ deploys in the window | | **Time to Restore** | How fast you recover | Median time from incident opened → resolved | ## Deploy signal: merges vs. actions Deployment Frequency and Lead Time depend on knowing when you ship. DevPerform supports two modes, set per org in **Admin → Org Settings**: Every merged pull request counts as a deploy. Lead time is measured **PR open → merge**. This works with zero CI configuration. A deploy is a **real successful deploy** from your host — a named GitHub Actions workflow run, or a GitLab / Bitbucket Deployment (you provide the workflow or environment name). Lead time is measured **merge → deploy**, attributing each shipped PR to the deploy that carried it. Use this when you have a real deploy pipeline and want production-accurate timing. ## Where failures come from Change Failure Rate and Time to Restore need incident data. DevPerform treats **issues carrying your org's incident label** as incidents (GitHub/GitLab labels; Bitbucket matches on title) — no separate incident tool required. Set the label in Org Settings. CFR is incidents ÷ deploys over the window; Time to Restore is the median open→close time of those issues. ## Bands Each key is labeled **Elite**, **High**, **Medium**, or **Low** against published DORA thresholds, so you can see at a glance where a team sits without memorizing target numbers. Bands are reference points for improvement, not grades. DORA is part of the **Growth** plan and up. See [Plans](/plans). # Flow & Review Health Source: https://docs.devperform.io/metrics/flow Phased cycle time, review health signals, and weekly trends. Beyond the single cycle-time number, DevPerform breaks down *where* work spends its time and *how healthy* your review process is. ## Phased cycle time Cycle time is split into four stages so you can see which part of the pipeline is slow: | Stage | From → to | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **First commit → open** | First commit → PR opened. Labeled for exactly what git observes: in commit-then-open workflows (AI agents especially) this gap is seconds — that's real, not missing data | | **Pickup** | PR opened → first review (or merge, if never reviewed) | | **Review** | First review → merged | | **Deploy** | Merged → deployed *(actions mode only)* | Shown as a stacked bar at the **team** level and on each engineer's own detail page as a **self-view**. A long pickup stage points to reviewers not getting to work; a long review stage points to back-and-forth on changes. The first-commit stage relies on first-commit data, which fills in as PRs are re-synced — newly tracked repos populate it gradually. ### Industry reference bands The coding, pickup, and review stages carry a small **"industry"** chip classifying your value against openly published benchmarks — LinearB's 2026 Software Engineering Benchmarks Report (8.1M+ pull requests across 4,800 teams), with the source and full thresholds in the chip's tooltip. Where DevPerform's stage definitions differ slightly from theirs, the tooltip says so and the comparison reads conservatively. The Team Dashboard's unreviewed-merges stat carries a similar published guideline (fewer than 5% of PRs bypassing review). These are context, not grades — your own trend matters more than any threshold. ## Review health Two signals on the Team Dashboard surface review-process risk: * **Unreviewed merges** — the count and percentage of merged PRs that shipped with **zero reviews**. A rising number is a quality/risk signal. * **Review depth** — the median number of comments per merged PR. Very low depth can mean rubber-stamping; this is a process signal, never a per-person score. Both respect the active team filter and date range. ## Trends The **Trends** view plots weekly throughput (PRs opened and merged) and median cycle time over time, so you can see whether a change is an improvement or just noise. Trends can be scoped to a team. ## Reading these together A healthy pattern is short, stable cycle time with consistent review depth and few unreviewed merges. When cycle time spikes, the phased breakdown tells you which stage moved, and the [executive view](/dashboard/executive) flags the week-over-week jump automatically. Phased cycle time and review health are part of the **Growth** plan and up. See [Plans](/plans). # Investment & Allocation Source: https://docs.devperform.io/metrics/investment See where engineering effort actually goes — features, maintenance, and keeping the lights on. The **Investment** view answers a question every VP of Engineering and CFO eventually asks: *where is our engineering time actually going?* DevPerform classifies merged work into categories and shows the split by effort. The investment mix, its week-over-week trend, effort-by-initiative, and [cost capitalization](/metrics/investment#cost-capitalization) all live together on the **Investment & Cost** page (Business section of the sidebar) — one home for effort-and-money questions. ## Categories Every merged PR is bucketed into one of: | Category | Title signals | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | **Features** | `feat:` / `perf:` — new capabilities and performance work | | **Maintenance** | `fix:` / `bugfix:` / `hotfix:` — bug fixes, patches, reverts, regressions | | **Keep-the-lights-on (KTLO)** | `chore:` / `refactor:` / `build:` / `ci:` / `docs:` / `test:` — refactors, dependency bumps, cleanup, infra, docs, tests | | **Uncategorized** | Anything that doesn't clearly match | Classification is derived from **PR titles** — conventional-commit prefixes first (`feat:`, `fix:`, `chore:`…), then a keyword fallback. It's a heuristic, not perfect labeling — DevPerform says so in the UI — but across many PRs it gives a reliable mix. ## The views * **Investment mix** — the share of effort (by lines changed) in each category for the selected period, as a single bar plus per-category breakdown. * **Per-team scope** — filter the mix to a team and its sub-teams to compare how different groups spend their time. * **Over time** — a weekly stacked bar on the [executive dashboard](/dashboard/executive) shows the mix shifting across the last several weeks, so you can see (for example) maintenance creeping up over a quarter. ## Why it matters A team spending 70% on KTLO is sending a clear signal about tech debt or operational load. Investment mix turns that from a gut feeling into a number you can track and act on — and it's the basis for the cost-capitalization / R\&D reporting that finance teams care about. ## Custom categorization rules When title conventions aren't enough — a repo that's entirely KTLO, a `platform/*` branch family that's always Features — admins can define **categorization rules** under **Admin → Settings → Investment categorization rules**. A rule matches PRs on structured fields, ANDed together: * **Repository** and **branch** (glob patterns, e.g. `infra-*` or `release/*`) * **Title** (contains, or a regex — validated when you save it) * **Changed file paths** (prefix, e.g. `docs/`) Rules are ordered by **priority — the first enabled rule that matches wins**, and anything no rule matches falls back to the title conventions above. The same rule engine drives the investment mix, the weekly trend, and cost capitalization, so the numbers always agree, and the views show how many PRs were rule-matched vs convention-categorized so the split stays explainable. Rules are **read-only analytics**: DevPerform never writes labels, reviewers, or anything else back to your code host. Rules recompute live, including for past periods — if you change rules after capturing a cost-capitalization report, re-running it can differ. Export the CSV when you need a point-in-time record. ## Improving categorization accuracy Categories come from PR titles, so title hygiene directly improves the mix. What the categorizer understands, in priority order: 1. **Conventional-commit prefixes** — `feat:`, `perf:` (Features); `fix:`, `hotfix:` (Maintenance); `chore:`, `refactor:`, `ci:`, `docs:`, `deps:` … (Keep-the-lights-on). The most precise signal — adopt these if you adopt nothing else. 2. **Version bumps** — `pkg: 1.2 -> 1.3`, "update foo to v2.1", any `A -> B` transition (KTLO). 3. **Recognizable shapes** — `init at X` (new component → Features), `[Backport …]` (Maintenance), `scope: remove/drop/disable` (Maintenance), `scope: use/move/replace/migrate` (KTLO). 4. **Branch prefixes** — `feat/…`, `fix/…`, `dependabot/…` rescue a PR whose title carries no signal. "Uncategorized" means none of the above matched — usually a title like *"various improvements"*. A team using conventional commits typically sees under 5% uncategorized. # The Open Benchmark Source: https://docs.devperform.io/metrics/open-benchmark Live industry percentile benchmarks computed daily from ~200 curated public open-source repositories. The **Open Benchmark** publishes live industry percentiles for the core delivery metrics — computed daily from a curated set of public open-source repositories, and served openly so anyone can see how the wider open-source world ships software. It's the population-level companion to the [free single-repo benchmark](/metrics/benchmark): one gives you the industry distribution, the other scores a repo you paste in. ## What it measures Percentiles are published for four delivery metrics: | Metric | What it is | | ------------------------ | --------------------------------------------------------------------- | | **Cycle time** | Median hours from PR opened to merged | | **Time to first review** | Median hours from PR opened to the first non-author review or comment | | **PR size** | Median lines changed per merged PR | | **Merge frequency** | Merged PRs per week | ## Where the numbers come from * **\~200 curated public repositories.** The panel is a hand-picked set of active, well-known open-source projects — each one **API-verified** as a real, public repository before it counts toward the distribution. * **Refreshed daily.** DevPerform recomputes the panel's metrics every day, so the published percentiles track the current state of the set rather than a one-time snapshot. * **Public metadata only.** The benchmark reads public pull-request metadata via the host API — no source code, and **no personal data** of any kind. It's repository-level metadata, nothing tied to an individual. The percentiles are available from the public app endpoint: ``` GET /api/public/benchmark/industry ``` ## How to read it honestly The panel is built from **public open-source repositories, and those skew differently from a private team's repos.** Open-source work tends toward larger contributor pools, asynchronous review across time zones, and drive-by contributions — all of which pull cycle time, review latency, and PR size in directions that a co-located product team wouldn't see. Treat the Open Benchmark as a **directional reference for the open-source population**, not a target line for your team. For a comparison that actually reflects *your* code, run your own repository through the [free benchmark](https://devperform.io/benchmark) at **devperform.io/benchmark** — it scores a single repo against published industry bands in seconds, no signup required. The Open Benchmark reflects public open-source repositories, which ship differently than private team repos. Use it to understand the open-source distribution; use the [free benchmark](https://devperform.io/benchmark) to see where a specific repo lands. # Plans & Features Source: https://docs.devperform.io/plans What's included in Free, Growth, and Pro. DevPerform comes in three tiers — **Free**, **Growth**, and **Pro**. Your plan controls which metrics and features are available; everything is gated by a single entitlement on your organization. Pricing is per engineer; see the [pricing page](https://devperform.io) for current details. **New accounts start with a 14-day Pro trial** — full access to every feature, no credit card required. When the trial ends you move to the Free plan automatically (nothing is charged); upgrade any time to keep Pro. | | **Free** | **Growth** | **Pro** | | ----------------------------------------------------------------------------------------------------- | -------- | ---------- | ------- | | Repo sync & roster (GitHub/GitLab/Bitbucket) | ✓ | ✓ | ✓ | | Team & engineer metrics | ✓ | ✓ | ✓ | | Burnout / overload flags | ✓ | ✓ | ✓ | | [DORA metrics](/metrics/dora) | | ✓ | ✓ | | [Phased cycle time & review health](/metrics/flow) | | ✓ | ✓ | | [Surveys](/surveys/overview) (DX, engagement, eNPS) | | ✓ | ✓ | | [Goals / working agreements](/goals) | | ✓ | ✓ | | [Slack integration](/integrations/slack) — digests, survey delivery, opt-in personal PR notifications | | ✓ | ✓ | | [Investment & allocation](/metrics/investment) with custom categorization rules | | ✓ | ✓ | | [Executive summary](/dashboard/executive) | | ✓ | ✓ | | [Rework / churn & hotspots](/metrics/code-quality) | | | ✓ | | [AI-native metrics](/metrics/ai-metrics) | | | ✓ | | Priority support | | | ✓ | Tier boundaries continue to evolve as features ship. The principle: **Pro** is where the AI-era and advanced/enterprise differentiators live. If you need a feature that's in a higher tier for an evaluation, get in touch. ## How billing works Your tier is stored on your organization. You can **upgrade from within the app** — the upgrade prompt opens hosted **Stripe checkout**, and a customer portal handles plan changes, invoices, and payment methods. Billing is per active contributor (an engineer assigned to a team); people you haven't put on a team don't count. [Get in touch](https://devperform.io) if you need help. # Quickstart Source: https://docs.devperform.io/quickstart Go from zero to a live dashboard in about 10 minutes. Go to [devperform.io](https://devperform.io) and click **Sign in with GitHub**, **GitLab**, or **Bitbucket** — whichever your team uses — and authorize DevPerform. Then connect your repos: GitHub grants org access (see [GitHub Org Setup](/github-org-setup)); GitLab and Bitbucket connect via a button (see [GitLab Setup](/gitlab-setup) and [Bitbucket Setup](/bitbucket-setup)), which auto-tracks your accessible repos. Whoever connects the code host becomes the account's admin and owner — there's no separate step. Installing the GitHub App or connecting GitLab/Bitbucket grants the admin role on the spot (those flows already require admin rights on the code host side). To bring in teammates, send invites from **Admin → People & Teams** and pick the **Member** or **Admin** role for each invite. Connecting GitLab/Bitbucket auto-tracks your repos; for GitHub (or to add more), in **Admin** add them as `owner/repo` (GitHub org/repo, GitLab `group/project`, or Bitbucket `workspace/repo`, e.g. `acme/backend`). All tracked repos are analyzed together. The first sync backfills history in the background. Under **Engineer Roster**, either click **Import your team** to seed your whole org / group / workspace at once ([details](/admin/import-members)), or add engineers manually. Each needs a name and at least one [handle](/concepts/engineers); handles can be multiple per person. Under **Teams**, create a team hierarchy and assign your engineers. **The analytics dashboards stay locked (shown blurred) until at least one engineer is assigned to a team** — assignment is how DevPerform knows who to count. You're billed only for assigned engineers, and your first 5 are free. The dashboard team filter scopes metrics to a team and its sub-teams. ``` Engineering ├── Platform └── Product ├── Frontend └── Backend ``` Open **Dashboard** for the team view (last 30 days by default). From there, explore the [Delivery & Quality dashboard](/metrics/dora), [trends and flow](/metrics/flow), and the [executive summary](/dashboard/executive). Use the date picker and team dropdown to scope any view. ## What's next Pair your delivery data with how the team actually feels. Commit to measurable working agreements and track them. Pick your deploy signal and incident label for accurate DORA. Find out which metrics your tier unlocks. # Surveys Overview Source: https://docs.devperform.io/surveys/overview Measure developer experience and team sentiment alongside your delivery data. Git metrics tell you *what* is happening; surveys tell you *why*. DevPerform includes a survey product so you can pair objective delivery data with how your team actually feels — and correlate the two. Surveys are part of the **Growth** plan and up. See [Plans](/plans). ## Survey types Pick one or more built-in templates when creating a survey, and add your own questions alongside them: * **DX Core 4** — a validated developer-experience framework measuring flow, feedback loops, and friction. Rolls up into a [DX Index](/surveys/results#dx-index). * **Full Engagement** — a comprehensive \~5-minute engagement survey across seven dimensions: **Manager, Growth, Recognition, Enablement, Wellbeing, Belonging**, and overall **Engagement**. Scored per dimension, with key-driver analysis that surfaces which dimensions (and which questions) most move engagement. Best for periodic deep reads (quarterly / half-yearly). See the [engagement scorecard](/surveys/results#engagement-scorecard). * **eNPS** — "how likely are you to recommend this as a place to work," scored on the −100 to 100 eNPS scale, with an open follow-up. * **Engagement** — a short team-satisfaction pulse (a lighter alternative to Full Engagement). * **Custom questions** — add your own Likert or open-text items to any survey. ## Managing surveys The **Surveys** page has two tabs: * **Manage** — create, edit drafts, send, resend, close, and **archive** surveys. Filter the list by status, time period, or search; archived surveys drop out of the list but their data is retained for trends and comparisons. * **Insights** — analyze results across surveys, teams, and time. See [Reading results](/surveys/results). Surveys are **account-wide**: they can reach engineers across all of your connected orgs / groups / workspaces, and you choose recipients **by team** (or the whole company) when sending — only people with an email on file can be sent to. ## How delivery works 1. **Map identities** — in Admin, map each engineer's handle to a work email so DevPerform knows where to send. (Emails are auto-filled from commit metadata, and you can add or correct one inline from the team roster.) 2. **Create a survey** — pick one or more templates, customize questions, and choose who receives it — by team or the whole company. 3. **Send** — DevPerform emails each engineer a unique tokenized link with a time estimate. They answer on a hosted page — **no login required**. Set an optional deadline. 4. **Reminders** — automatic reminders nudge people who haven't responded before the deadline. Slack delivery (higher response rates) is on the roadmap; email is the channel today. ## Anonymity by default Engineers' individual answers are never exposed. Results only become visible once a survey (or a filtered segment) has at least the **minimum number of responses** — **4 by default**, configurable in Org Settings. Below that threshold, DevPerform shows "not enough responses yet" instead of anything that could de-anonymize a small group. This is core to the product's stance: surveys are for understanding the team, not surveilling individuals. See [Reading results](/surveys/results). # Reading Survey Results Source: https://docs.devperform.io/surveys/results The engagement scorecard, key drivers, comparisons, and trends — with anonymity built in. Once a survey clears the [anonymity threshold](/surveys/overview#anonymity-by-default), its results unlock under the **Insights** tab of the Surveys page. DevPerform goes beyond raw averages to help you find what to actually do. A single survey's results page is split into two tabs: **Overview** (the Experience Index, follow-through from the previous wave, focus-area triage, per-dimension scores, the team heatmap, and the experience-vs-delivery drivers) and **Questions** (every question's full results, filterable by question set — DX Core 4, Engagement, AI Impact, eNPS). Use the team filter to scope either tab to one team. ## Engagement scorecard A [Full Engagement](/surveys/overview#survey-types) survey is shown as a **scorecard** — the whole instrument on one page: * **Overall engagement** — a single 0–100 score, with the change since your previous wave. * **Every dimension** — Manager, Growth, Recognition, Enablement, Wellbeing, Belonging, and Engagement — each with its score, a bar, and the wave-over-wave change. Use the **Team** selector to scope the entire scorecard (overall, dimensions, drivers, and comparison) to a single team. A team's scores stay hidden until it clears the anonymity threshold on its own. ### Key drivers Driver analysis finds which dimensions most **correlate with engagement** across respondents — the levers that actually move it. A dimension with **high impact but a low score** is flagged as a **focus area**: high leverage, currently weak. Click any dimension to drill into **which of its questions** are doing the driving, so you go from "Growth is dragging engagement" to the specific item behind it. Key-driver analysis is a correlation, so it needs a few responses to be meaningful — it stays hidden until a survey has enough. ### Compare over time Pick **any two administrations** to compare (this quarter vs. last, H1 vs. H2, year over year) and the overall and per-dimension deltas update to that baseline. An **overall-engagement trend line** plots every wave so you can see the trajectory at a glance. ## DX Index For DX-style surveys (DX Core 4 and other Likert templates), responses roll up into a single trackable **DX Index** — one number you can watch over time, rather than juggling a dozen question scores. ## Compare across teams and time The Insights explorer lets you trend any single metric — **Engagement / DX Index, eNPS, or response rate** — over time, with one line per team plus a company-wide overall, and a current-period bar comparison across teams. Pick the metric, the teams, and a date range. ## Per-survey heatmap For a single survey, the heatmap shows scores by question across teams, so you can spot at a glance which group is struggling with which dimension. It respects the anonymity threshold per cell — small segments stay hidden. ## Delivery driver analysis Beyond the in-survey key drivers above, DevPerform can correlate survey sentiment with your **actual delivery telemetry** — connecting, for example, low scores with measured cycle-time or review-pickup data. This is unique to having both datasets in one place: it ties how the team *feels* to how it's *delivering*. ## Saved views Save a metric + team + filter combination as a **named view**, shared across your account's admins — so "Engagement by Platform team" or "eNPS, last quarter" is one click away for everyone. ## Anonymity, everywhere Every scored view — the scorecard, dimensions, drivers, comparisons, heatmap cells, and trends — enforces the minimum-response threshold. If a segment is too small to be anonymous, its numbers are withheld rather than shown. (Response rate, a participation count rather than an answer, is always available.) ## The Experience Index Every survey's likert questions roll up into a single **Experience Index** (0–100): each 1–5 question is averaged across respondents, those averages are averaged, and the result rescales to 0–100. eNPS, free-text, and quantitative bucket questions never feed it. The results page shows the index with a trend against your previous survey wave (waves suppressed by the anonymity threshold are skipped, never leaked), per-team indices under the same thresholds, and a "how is this computed?" breakdown — one number is a conversation starter, not a verdict. Where a survey includes eNPS, results show the standard interpretation bands (above 0 good, above 20 favorable, above 50 excellent, above 80 world class — the Bain & Company thresholds as published by Qualtrics; the UI notes this is the general NPS scale, not an engineering-specific benchmark). ## Focus areas — closing the loop Admins can triage each survey dimension right on the results: mark it **Focus**, **Watching**, or **No action**, with a short note ("pairing rotation starts next sprint"). Statuses and notes are **visible to the whole team** — the point is that everyone sees leadership responded, which is what keeps response rates healthy. Marking a dimension as Focus offers one-click goal creation: a real goal targeting that survey dimension (e.g. "Ease of delivery above 69/100") that evaluates automatically against each new survey wave. When your next survey closes, its results open with **follow-through receipts**: the previous wave's Focus and Watching areas with their score deltas — commitment, then evidence. Dimensions suppressed by the anonymity threshold can't be triaged and never appear in comparisons.