Linear Analytics: Measuring Flow Without Ceremony

Most attempts at Linear analytics die the same way. Someone exports issues to a spreadsheet, builds a velocity chart, presents it once, and never touches it again. Two months later the team still cannot answer the only questions that matter: is work moving faster or slower than it was, where does it stall, and are we finishing what we start.

The problem is not the tooling. Linear already records nearly everything you need, with clean timestamps and a strict state model. The problem is that teams measure the things that are easy to count instead of the things that describe flow. This guide covers the four measurements that survive contact with a real engineering team, how to define them so they cannot be gamed, and how to pair them with repository activity so the picture is honest rather than flattering.

What Linear analytics actually measures

Linear's data model is unusually well suited to flow measurement because state is not freeform. An issue lives in a workflow state, each state belongs to a type (backlog, unstarted, started, completed, canceled), and transitions are recorded in the issue's history with timestamps. That means you can reconstruct the life of any issue without asking anyone to fill in a field.

Three sources of truth are available, and they answer different questions:

Built-in insights and views. As of 2026, Linear ships analytics inside views: you can group, filter, and chart issue counts and estimates, and cycle views include a burn-style graph showing scope against completion. This is enough for a team lead who wants a weekly read without infrastructure. Check Linear's current documentation, because this surface has been expanded repeatedly.

CSV export. Fast, ugly, and fine for a one-off investigation. You lose history, so you can compute lead time but not time-in-state.

The GraphQL API. This is where real Linear analytics lives. Issues expose creation, start, and completion timestamps, and issue history entries expose every state transition, label change, cycle assignment, and estimate change. Webhooks let you capture the same events as they happen. If you want time-in-state percentiles or scope-change tracking, this is the only complete source.

A caution before any of it: these metrics describe a system, not people. The moment cycle time appears next to an individual's name in a performance conversation, engineers optimize for the metric. Issues get split into slivers, tickets get moved to "In Progress" the moment they are opened, and the data stops meaning anything. Measure the team, the queue, and the workflow.

Cycle time, defined so it survives an argument

Cycle time is the elapsed time between the moment work genuinely starts on an issue and the moment it is done. In Linear terms, it is the first transition into a state of type started through the transition into a state of type completed.

Two neighbouring metrics get confused with it constantly:

• Lead time runs from issue creation to completion. It includes however long the issue sat in the backlog, which is a prioritization measurement, not an execution one.
• Time to first response runs from creation to first human touch. That is a triage metric and belongs in its own section.

All three are useful. Reporting one while calling it another is how teams end up arguing about whether they got faster.

Use percentiles, never averages

Cycle time distributions have long tails. One issue that sat in review for three weeks will drag the mean far away from the lived experience of the team. Report the median (p50) and the 85th percentile (p85) together. The median tells you what a normal item feels like. The p85 tells you what your worst realistic case is, which is the number a stakeholder actually needs when asking "when will this be done."

If p50 is stable and p85 is growing, you do not have a speed problem. You have a variability problem, and variability usually comes from queues: waiting for review, waiting for QA, waiting for a decision.

Break cycle time into states

A single cycle time number tells you the patient has a fever. Time-in-state tells you where the infection is. Reconstruct, per issue, how long it spent in each workflow state, then look at the distribution per state rather than per issue. In most teams the coding state is not the expensive one. The expensive ones are "In Review" and whatever state means "waiting for someone else."

This is the single highest-value thing you can build on top of Linear's API, and it is also the thing built-in charts are least likely to give you out of the box.

Watch the started-state hygiene problem

Cycle time is only as good as the moment you call "started." Two habits corrupt it: dragging everything into In Progress at sprint planning, and leaving finished work sitting in a started state until someone remembers to close it. Neither is malicious. Both make cycle time meaningless. If your median cycle time is suspiciously close to your cycle length, you are measuring calendar ceremony, not flow.

Scope creep: the metric your cycle chart is already hiding

Linear's cycle graph plots scope against completion over the life of a cycle. The line most people ignore is the scope line. When it climbs mid-cycle, issues were added after the cycle started. That is scope creep, and it is the most under-measured signal in engineering delivery.

To measure it properly, track four numbers per cycle:

Added scope divided by committed scope is your interruption rate. If it sits consistently high, the honest read is not that the team is undisciplined. It is that the cycle is a fiction and the real intake is unplanned. Two legitimate responses exist: reserve explicit capacity for interrupt work, or stop pretending cycles are commitments and run a continuous flow model with a work-in-progress limit instead.

Carryover deserves special attention. One issue rolling over is noise. The same issue rolling over four cycles in a row is a signal that it is too large, blocked on something nobody owns, or not actually important. A rule worth adopting: any issue that carries over twice gets split or closed. Nothing carries over three times.

Where estimates fit, and where they do not

Estimate points are useful for scope tracking within a cycle because they capture that "add one large issue" is not the same as "add one small issue." They are close to useless for cross-team comparison, because point scales drift. If you only ever count issues, you will underreact to a single enormous addition. If you only ever count points, you will chase inflation. Track both, and never compare point velocity between two teams.

Triage health is a customer metric, not a support metric

Linear's Triage inbox is where inbound work lands: bug reports from support, requests from other teams, alerts from integrations. It is also the part of the system most likely to rot quietly, because nobody owns a queue that belongs to everyone.

Four measurements keep it honest:

Time to first triage decision. From arrival in Triage to acceptance, decline, or merge as duplicate. Report p50 and p85. This is the number a support team feels directly.

Triage backlog age. Not the count, the age. A queue of forty items where the oldest is two days old is healthy. A queue of eight where the oldest is five weeks old is not. Track the age of the oldest item and the p85 age.

Disposition mix. What fraction of triaged items become accepted work, get declined, or get merged into an existing issue. A high duplicate rate means your search or your intake form is failing. A high decline rate that arrives weeks late is worse than a high decline rate that arrives in a day, because the requester spent that time believing something was happening.

Reopen rate. Issues that were completed and returned to an active state. This is the closest thing Linear gives you to a quality signal, and it pairs directly with change failure rate on the repository side.

Triage is where the connection between engineering and the rest of the business is most visible, which is why it belongs in the same weekly review as revenue and pipeline signals rather than in a separate engineering ritual. The same logic that makes Slack conversation patterns worth reading applies here: the queue nobody looks at is the one that tells you what is really happening.

Pairing Linear analytics with repo activity for an honest delivery view

Linear tells you what the team intended and when it declared work done. Your repository tells you what actually shipped. Neither is sufficient alone, and the gap between them is where most delivery pain lives.

The DORA research program, published by Google Cloud, popularized four delivery measures: deployment frequency, lead time for changes, change failure rate, and time to restore service. Three of those come from your repository and deploy pipeline, not from your issue tracker. Combining them with Linear data gives you a view neither system produces on its own.

Two joins make this practical. First, branch and PR naming that includes the Linear issue identifier, which Linear's Git integrations rely on anyway. Second, a consistent definition of "shipped." Pick one: merged to the default branch, or deployed to production. Write it down. Half the disagreements about engineering metrics are two people using different definitions of done.

The most useful derived number from the pairing is review latency: the time between a pull request opening and the first substantive review. It is almost never tracked, it is entirely within the team's control, and it frequently accounts for a large share of the tail in cycle time. If you build one thing beyond cycle time, build this.

Turning Linear analytics into a weekly habit instead of a dashboard

A dashboard nobody opens is a rounding error on the effort you spent building it. The habit that works is a short written read, delivered to where the team already talks, answering five questions:

1. Cycle time p50 and p85 this week against the trailing four-week values.
2. Added scope as a fraction of committed scope for the current cycle.
3. Issues that carried over for a second time, by name.
4. Oldest item in Triage, and how old.
5. Open pull requests with no review after 24 hours.

That is a five-line message. It takes about twelve minutes to read and discuss, and it produces decisions rather than admiration.

Where Skopx fits, and where it does not

Skopx is an AI workspace that connects to nearly 1,000 business tools and lets you ask questions and take actions across them in chat. For Linear analytics specifically, that means you can ask about your issue data in plain English and get an answer that cites where it came from, without exporting anything.

Compare median and 85th percentile cycle time for the Platform team over the last four Linear cycles, list every issue that carried over more than once, and show which GitHub pull requests linked to those issues sat more than 24 hours without a review.

That returns a written answer with the numbers, the named issues, and the pull requests, sourced from the connected Linear and GitHub accounts rather than a static export. You can then ask the follow-up questions that a chart cannot answer, like why a specific issue stalled, and get the history behind it.

You can also turn that read into a recurring one. Skopx workflows are automations you build by describing them in chat rather than dragging boxes on a canvas. A schedule trigger runs the query every Monday morning, an AI step written on your own model key drafts the five-line summary, and an integration action posts it to the team channel. Real limits apply and are worth knowing before you plan around them: workflows are acyclic, capped at 20 steps, have no human-approval step and no custom code step, and AI steps require your own provider key. The minimum schedule interval is 15 minutes. Skopx also produces a daily morning brief that surfaces what changed and what is slipping across connected tools, which covers the "what moved overnight" question without you building anything.

Now the honest part. Skopx is not a business intelligence tool. It does not build drag-and-drop dashboards, and it will not give you an interactive cycle time chart you can slice by hovering. If your organization needs a persistent visual dashboard that a director can filter themselves, use a dedicated BI tool on top of a warehouse, or lean on Linear's own insights views. Skopx is the right tool when the job is answering questions, generating written reports, alerting on conditions, and automating the follow-up actions. Those are different jobs, and pretending otherwise would waste your time.

The same division of labour applies elsewhere in the stack. It is the pattern behind reading payments data like an operator and behind answering pipeline questions in plain English rather than commissioning a report. Pricing is straightforward and paid from day one: Solo is $5 per month, Team is $16 per seat per month with no seat cap. There is no free tier and no trial, so evaluate it the way you would any tool you intend to keep. Details are on the pricing page, and the connectable tools are listed under integrations.

Frequently asked questions

What is a good cycle time in Linear?

There is no universal target, and anyone quoting one is selling something. What matters is your own trend and your own variability. A team shipping infrastructure changes will have a legitimately longer cycle time than a team shipping copy edits. Watch the direction of p50 and the gap between p50 and p85. A narrowing gap means your process is becoming predictable, which is usually more valuable to the business than raw speed.

Can I get time-in-state metrics from Linear without writing code?

Partially. Linear's built-in views and cycle graphs cover scope, completion, and grouping well. Full time-in-state percentiles require reconstructing transitions from issue history, which means the GraphQL API, webhooks, or a tool that queries the data for you. Check Linear's current documentation before assuming, because the built-in analytics surface has been expanded several times.

How do I connect Linear and GitHub data without a warehouse?

If you only need answers rather than a dashboard, a question layer over both connected accounts is enough: ask across the two systems and let the tool join on issue identifiers embedded in branch and pull request names. If you need historical trend charts, versioned metrics, and slicing by arbitrary dimensions, you do need somewhere to store the history, and a warehouse plus a BI tool is the correct answer.

Should scope creep be reported to leadership?

Yes, and it is usually the most persuasive number engineering can bring to a planning conversation. Added scope as a fraction of committed scope reframes "the team missed the cycle" as "the team absorbed a third more work than was planned." That is a prioritization discussion rather than a performance one, which is the discussion you actually want to have.

Do these metrics work for a continuous flow team with no cycles?

Most of them, yes. Cycle time, time-in-state, triage health, and review latency need no cycles at all. Scope creep and carryover are cycle-specific by construction. Flow teams should replace them with work-in-progress count and queue age, which measure the same underlying pressure: too much started, not enough finished.

Is it safe to connect Linear to an AI workspace?

Ask any vendor the same questions you would ask of any system touching internal work: encryption at rest and in transit, isolation between organizations, whether your data is used for model training, and what actions the tool can take without asking. For Skopx specifically, data is encrypted with AES-256 at rest and TLS 1.3 in transit, each organization's data is isolated at the row level, actions require your approval, and your data is never used to train a model. Skopx has SOC 2 controls in place. Scope the integration's permissions to read-only first if your policy calls for it, then widen once you trust the behaviour.

The short version

Measure cycle time as a distribution, not an average. Split it by state so you can see queues instead of guessing. Track added scope and carryover, because they explain missed cycles better than any velocity chart. Keep triage age visible, because it is where the rest of the company experiences your engineering process. Then join all of it to what actually merged, because an issue tracker records intention and a repository records fact.

None of this requires a new ceremony. It requires five numbers, one weekly message, and the discipline to define "started" and "done" once and stick to it. Everything else is decoration.