Linear + DORA Metrics: How to Use Linear Issue Data to Track Engineering Velocity

Why Linear Has Become the Dominant Issue Tracker for Modern Engineering Teams

Linear launched in 2020 with a simple thesis: issue trackers had been designed for project managers, not engineers. The result was a product that felt like software — fast, keyboard-driven, with a UI closer to Figma or VS Code than to Jira. The engineering community noticed immediately.

By 2024, Linear had become the default tracker for a specific segment that matters disproportionately to the industry: high-velocity product engineering teams at companies like Vercel, Stripe, Ramp, Mercury, and Linear's own internal teams. These are the teams that other teams benchmark against. When engineering leaders at Series A startups evaluate tooling, they look at what those companies use. Linear consistently shows up.

The speed advantage is real and measurable. Linear's Electron-based desktop app and web client cache aggressively, making search and navigation feel near-instant on large issue databases. Keyboard shortcuts cover nearly every workflow — triage, state transitions, assignment, label application — without a mouse. Cycle-based planning (Linear's term for sprints) is built into the data model rather than bolted on as a reporting layer. Teams that switch from Jira consistently report faster daily issue management workflows.

For engineering metrics purposes, Linear's data model has one important advantage: timestamps are reliable. Every state transition — created, started, in review, completed — is logged with a precise timestamp. The GraphQL API exposes these directly, which makes cycle time and flow calculations straightforward once you understand the query structure.

What Linear Can Contribute to DORA Metrics

Linear does not have a deployment concept. It has no awareness of what code was released to production, when a pipeline ran, or whether a deploy succeeded. But it does hold the upstream half of the delivery chain — the issue lifecycle from creation through completion — and that is where several DORA signals originate.

Lead Time for Changes

DORA defines Lead Time for Changes as the time from a code commit entering the main branch to that change being live in a successful production deployment. Linear can contribute the upstream segment: from issue creation (or "started" state transition) to the point where a pull request is opened.

When your team uses Linear's GitHub integration and embeds issue IDs in branch names and PR titles — a pattern like feature/LAT-123-add-export — you can trace the full chain:

1. Linear issue created — the moment work enters the backlog (createdAt timestamp)
2. Issue moved to "In Progress" — when an engineer picks it up (startedAt timestamp)
3. PR opened — via GitHub webhook or Linear GitHub app, visible as an attachment on the issue
4. PR merged — the commit enters the main branch
5. Deployed to production — the final timestamp from your deployment pipeline

Linear owns steps 1–3 in this chain. GitHub owns 4. Your deployment system owns 5. Full end-to-end lead time requires all three data sources joined on the issue ID and commit SHA.

Change Failure Rate

Change Failure Rate measures the percentage of deployments that cause a production incident requiring remediation. Linear contributes the incident signal when your team creates Bug or Incident type issues in Linear in response to production problems.

The calculation logic: for every production deployment timestamp from your pipeline, look for Linear issues of type Bug or with an Incident label that were created within a short window after that deployment — typically 1–4 hours. Issues created in that window are strong candidates for escaped defects from that release.

This is an approximation. It works well for teams that have a disciplined habit of creating Linear issues for every production bug. It underestimates CFR for teams that handle production issues in Slack and only create tickets retroactively — or not at all.

MTTR: Incident Issues from Triage to Resolved

Mean Time to Restore measures how quickly a team recovers from a production incident. When your team uses a dedicated Incident label or a separate Linear project for production incidents, the MTTR calculation is the delta between createdAt (when the incident issue was opened) and completedAt (when it was marked Done or Resolved).

Linear's state model gives you more granularity than just open/closed. If your workflow has states like Triaged, Investigating, Mitigated, and Resolved, you can measure time-to-triage and time-to-mitigate separately — which is more actionable than a single MTTR number when you're trying to improve incident response.

Work In Progress and Flow Metrics

Linear's cycle model and issue state timestamps make it an excellent source for flow metrics that complement DORA:

• Cycle time per issue — from startedAt to completedAt, representing actual active work time per issue
• WIP count — issues in "In Progress" or "In Review" states at any point in time, queryable via the Linear API with state type filters
• Issue throughput per cycle — count of completed issues per Linear cycle (sprint), broken down by team
• Queue age — how long issues have sat in "Todo" state before being started, which predicts future lead time problems

The Linear GraphQL API: Queries You Need

Linear exposes all its data through a single GraphQL endpoint at https://api.linear.app/graphql. Authentication uses a personal API key or OAuth access token in the Authorization header. The schema is well-designed — most fields you need for metrics are available on the top-level Issue type without complex traversal.

Completed Issues with Cycle Time

{
  issues(filter: { state: { type: { eq: "completed" } } }) {
    nodes {
      id
      title
      identifier
      createdAt
      startedAt
      completedAt
      cycleTime
      team {
        name
      }
      labels {
        nodes {
          name
        }
      }
      attachments {
        nodes {
          title
          url
        }
      }
    }
  }
}

The cycleTime field is Linear's native cycle time calculation — the number of seconds from startedAt to completedAt. You can compute it yourself from the raw timestamps if you want to normalize differently (for example, excluding weekends).

The attachments field is where Linear stores GitHub PR links when the Linear GitHub app is connected. Each attachment has a url pointing to the GitHub PR — this is your join key to the GitHub side of the lead time calculation.

Cycle Data for Sprint-Level Throughput

{
  cycles {
    nodes {
      id
      number
      startsAt
      endsAt
      completedIssues {
        nodes {
          id
          cycleTime
          estimate
          labels {
            nodes {
              name
            }
          }
        }
      }
    }
  }
}

This query gives you throughput per cycle — both by issue count and, if your team uses story point estimates, by estimated scope. The cycleTime distribution across completedIssues within a cycle tells you whether cycle time variance is stable or increasing, which is an early warning signal for process problems.

Team Breakdown with State Distribution

{
  teams {
    nodes {
      id
      name
      issues(filter: { updatedAt: { gte: "2026-02-01T00:00:00Z" } }) {
        nodes {
          id
          state {
            name
            type
          }
          createdAt
          startedAt
          completedAt
          cycleTime
        }
      }
    }
  }
}

The state.type field is normalized across all Linear workspaces — backlog, unstarted, started, completed, cancelled. Using type rather than the customer-defined state name means your metrics code works across teams that name their states differently.

Webhook Events for Real-Time Metrics

For streaming metrics rather than batch polling, Linear supports webhooks on all resource types. The events relevant to DORA and flow metrics are:

• Issue.create — new issue enters the system; start tracking queue age
• Issue.update — state transition; capture startedAt, completedAt, label changes for incident detection
• Comment.create — useful for MTTR signal; first comment on an incident issue often indicates triage has started

Webhook payloads include the full issue object at the time of the event, so you do not need a follow-up GraphQL query to get the updated state.

Linking Linear Issues to GitHub PRs

The join between Linear and GitHub is what makes end-to-end lead time possible. There are three mechanisms Linear provides for this connection, in order of reliability:

Linear's Native GitHub App

When you install the Linear GitHub app, Linear automatically attaches a link to any pull request whose branch name or PR title contains a Linear issue identifier (the TEAM-NUMBER format, like ENG-42). These links appear as attachments on the issue and as "Development" metadata on the PR in the GitHub UI.

This is bidirectional: the GitHub PR shows the linked Linear issue, and the Linear issue shows the PR URL as an attachment. For metrics purposes, the attachment on the Linear issue side is more reliable because it survives PR renames and branch force-pushes that can break reverse lookups.

Smart Commit Messages with Issue IDs

Many teams enforce a convention where commit messages and branch names include the Linear issue identifier. A branch named feature/ENG-234-webhook-retry and a PR title like [ENG-234] Add exponential backoff to webhook retry are enough for Linear's app to auto-link. If the app is not installed, you can parse these patterns directly from the GitHub Commits API and PR title fields to build the join yourself.

PR Title Pattern Matching

For teams without strict branch naming conventions, you can fuzzy-match PR titles against Linear issue titles as a fallback. This is less reliable — a PR titled "Fix export bug" could match multiple Linear issues — but it provides signal coverage for teams that are still establishing conventions.

Linear-Specific DORA Calculation Patterns

Once you have issue timestamps and optional PR links from Linear, several useful calculation patterns emerge that go beyond raw DORA numbers.

Cycle Time Distribution: P50, P75, P95

Report cycle time as a percentile distribution, not a mean. Linear cycle times are right-skewed — most issues complete in a few days, but occasional large issues or blocked work creates a long tail that inflates the mean while the median stays flat.

A healthy team sees P50 stable or trending down over time, P75 no more than 2–3x P50, and P95 not growing cycle-over-cycle. When P95 grows faster than P50, you have an increasing tail of stuck or blocked work that is not showing up in the median — a common sign of an expanding backlog of deprioritized issues that never truly get resolved.

Issue Completion Velocity Per Team

Throughput — issues completed per cycle — is a more honest velocity signal than story points because it does not require estimation discipline. When normalized to team size, it gives you per-engineer output that is comparable across teams of different sizes.

The key is to track the trend, not the absolute number. A team completing 20 issues per cycle consistently is healthier than a team swinging between 5 and 40 per cycle, even if the latter has a higher average. High variance in throughput is a leading indicator of planning problems, dependency bottlenecks, or frequent context switching.

Escaped Defect Rate

Escaped defect rate measures the proportion of issues that were marked Done or Deployed and later had a linked Bug issue created. Linear's issue link types include a blocks and relates to relationship, but most teams use the duplicate or free-text parent links to connect bugs to their source features.

A simpler approach: count Bug-type issues created within 7 days of a related feature issue being completed and in the same team. Divide by total completed feature issues in the same window. This approximates the percentage of features that escape quality checks and requires a post-completion fix.

What Linear Does Not Give You

Linear's data model is comprehensive for the issue lifecycle, but it has hard limits for DORA measurement that no amount of GraphQL querying can work around.

Deployment Frequency Raw Data

Linear has no concept of a deployment. Completing a Linear issue does not mean code was deployed — it means the issue was moved to a completed state. Teams routinely complete issues in Linear before the PR is merged, after the PR is merged but before the deploy, or on a release day for a batch of issues that go out together.

Deployment Frequency must come from your actual deployment pipeline. GitHub Actions workflow runs, Vercel deployment webhooks, Railway deployment events, or a custom deployment record API are all valid sources. Linear alone cannot give you this number.

Actual Deploy Success and Failure

Even if you create a Linear issue every time a deploy fails, the fact of a failed deploy is a property of the deployment system, not the issue tracker. Change Failure Rate calculated purely from Linear bug creation rates will always lag the actual failure signal — bugs are created after the incident is investigated, not at the moment the deployment fails.

For accurate Change Failure Rate, you need deployment pipeline data with pass/fail status per deploy, correlated with post-deploy incident signals from either Linear or a dedicated incident tool.

Real MTTR from Production Incidents

Linear MTTR based on issue timestamps measures the time from when someone created a Linear ticket to when they closed it. This is not the same as the time from when the production incident started to when service was restored.

There is always a gap between an incident beginning (users experiencing degraded service) and an incident being logged in Linear (an engineer creating the ticket). For teams with a dedicated on-call workflow — PagerDuty, OpsGenie, incident.io — the incident timestamp from those tools is the authoritative MTTR start, not the Linear issue creation time.

Koalr: Complete DORA from Linear and GitHub Together

Koalr's Linear integration connects to your Linear workspace via OAuth and ingests issue data continuously using webhooks. On the GitHub side, Koalr connects to your repositories and deployment workflows. The two data streams are joined automatically on issue identifier patterns in branch names, PR titles, and commit messages.

The result is a complete DORA picture that neither tool can produce alone:

• Lead Time for Changes — traced from Linear startedAt through PR open, PR merge, and production deployment, with each segment displayed separately so you can see where time is actually spent
• Deployment Frequency — from GitHub Actions workflow runs or deployment events, matched to the Linear issues they contain so you can see deployment frequency per team, not just per repository
• Change Failure Rate — combines deployment pipeline failure status with Linear Bug/Incident issues created within the detection window after each deploy, giving you both the immediate signal and the delayed signal in one number
• MTTR — uses Linear incident issue timestamps as a fallback, but prioritizes PagerDuty or incident.io alert timestamps when those integrations are connected, for the most accurate incident-start time
• Cycle time distribution — P50/P75/P95 breakdowns per team and per label type, with week-over-week trend tracking

For a complete introduction to the four DORA metrics and how they are calculated across any tool stack, see the complete DORA metrics guide.