To see which client projects are At Risk or Off Track in Linear, group each client's projects under an initiative or label, then open one Projects view grouped by health. To find what is driving each project's health, check the lead's update against a few signals: target date versus progress, scope growth, blocked or idle issues, a stale update, the completion trend, and waiting on the client. Write each cause down with an owner and a next step.
How do I see every client project's health in one Linear view?
A single portfolio view comes from grouping client projects first, then grouping or filtering by health. Linear's Initiatives view lets leadership see progress across projects "without needing to drill down into each individual project," and Linear's changelog notes that projects can be grouped by update health.
Steps:
- If you will group clients as initiatives, turn on initiatives under Settings > Initiatives, as the Initiatives docs describe.
- Group each client's projects under one initiative or one label named [Client name] (see the next section for which fits your practice).
- If you use initiatives, open the workspace Initiatives view for a client-level read. According to the Initiatives docs, the Active Projects column rolls up each project's latest update by color: green on track, yellow at risk, red off track, gray with no current update.
- For the cross-client list you will use every week, open Projects and group by health, which the changelog announced. Filter to your delivery teams and save this Projects view as [Client portfolio: health]. The weekly review below uses this view together with a second view for client waits.
- Treat gray as its own category. A project with no current update is an unanswered question, and it can hide a real problem.
Should each client be an initiative or a label?
Each client should usually be an initiative when its projects share an objective, and a label when you need a category that cuts across initiatives. Linear's Initiatives docs say to use initiatives for "an intentional set of projects tied to a shared objective" and note that labels help with "cross-cutting categories."
| Approach | Use it when | Watch for |
|---|---|---|
| One initiative per client | You want a client-level health rollup and owner | The Initiatives docs list custom Initiative views as Enterprise only; the workspace Initiatives view with its Active Projects rollup is described separately, so check your plan. |
| A project label per client | Projects already sit under practice or service-line initiatives | You filter rather than roll up |
| A link to the client record in project Resources | You keep account data in a CRM | Automattic's handbook links each project to its partner record this way |
Pick one convention, write it in your delivery playbook, and check new projects against it when they are created.
What should At Risk and Off Track mean in our practice?
At Risk and Off Track should mean the same thing in every client project, so a partner can compare them. Linear's update docs let the lead pick a health of On track, At risk, or Off track with each update, but they leave the criteria to you. Agree yours with your leads and paste them into the project template.
Template to adapt:
- On Track: The current milestone will land by [target date] with the agreed scope. No sponsor decision is overdue.
- At Risk: One of these is true: progress is behind the plan for [milestone], scope has grown since [baseline date], key issues are blocked or idle, or a client review or decision is late. Recovery is possible with action this cycle.
- Off Track: The target date or scope will not hold without a change that needs the client or a partner: a new date, a scope cut, or more people.
For reference, the summary shown for a Sentry agent skill's listing on mcpservers.org says it flags a project as at risk when there are two or more bad signals, or one signal that seriously threatens the target date. Those are that skill's own rules, not a benchmark. Counting signals is still a useful habit to adapt.
What is driving each project's health?
Each project's health is usually driven by one of a few causes: a slipping date, scope growth, blocked or idle issues, a stale update, a falling completion trend, or a wait on the client. Most of these causes show up in Linear itself, so read the update text first and then check the project against the signals below.
| Signal | Where to look in Linear | What it usually means | Likely owner |
|---|---|---|---|
| Target date versus progress | The project's progress report, which Linear's update docs say covers issues completed, milestones, and target date changes, and appears only when progress has changed by more than 2%. A missing report does not prove nothing moved. | The date has moved, or work is landing too slowly for it | Delivery lead |
| Scope growth | One way to check is to open the project's issues and compare issues added since [baseline date] with issues completed in the same period. As one example, the listing summary on mcpservers.org says the Sentry skill flags a target date less than 30 days away while new issues are still being added at a meaningful rate. | Scope may be growing faster than work gets done; treat it as a prompt to ask, not a threshold | Lead and client, if it is a contract change |
| Blocked or idle issues | Issues in the current milestone that have not moved | A dependency, a missing person, or an unclear next step | Issue owner |
| Stale update | The project's health icon; Linear's update docs describe a dashed outline when an update is slightly overdue and a gray icon after a longer gap | Nobody has looked recently | Project lead |
| Waiting on the client | Your [Client portfolio: waiting on client] view (see the client section below) and the update text | A review, approval, access, or decision sits outside your team | Client sponsor, chased by the lead |
| Completion trend | The initiative graph, which the Initiatives docs say shows each project's rate of completed issues over time; available when clients are grouped as initiatives | Throughput has dropped | Lead |
Where the evidence and the health disagree, write the evidence into your notes and ask the lead about it.
How do I tell when "On Track" isn't true?
An On Track health is not true when the evidence in the project points the other way. Look for On Track projects with a moved target date, a stalled milestone, new scope near the deadline, or a client item that has waited a long time. The lead picks the health with each update, as Linear's update docs describe, so it reflects the lead's judgement at that moment.
A quick check for each On Track project:
- Has the target date changed since the last update?
- Is the current milestone's completed work moving?
- Were issues added recently that the update does not mention?
- Is anything labelled [Waiting on client] older than the last update?
If any answer is yes, comment on the update and ask the lead. Wording to use: "[Lead name], the update says On Track, and I can see [signal]. Is that already in hand, or should we look at it together before [client meeting]?"
How do I see which risks sit with the client?
Client-side risks stay visible only if your team marks them the same way every time. Add a workspace label such as [Waiting on client], ask leads to apply it to any issue held up by a client review, approval, access, or decision, and keep those issues in their own saved issue view next to your health view.
Steps:
- Create the [Waiting on client] label and add it to your delivery playbook.
- In each update, ask for a short line naming the item, who on the client side owns it, and when it was requested.
- Keep the [Client portfolio: health] Projects view for health. Separately, create a saved issue view filtered by the [Waiting on client] label and grouped by project, and name it [Client portfolio: waiting on client].
- Read the rows. Each row tells you who to call and what to ask for.
Wording for the follow-up: "[Sponsor name], we are waiting on your [decision / review / access] for [item], requested on [date]. Could you [action] by [date]?"
Unblockd supports asks to the sponsor by email with one-tap answers (no account), or answered by replying to the email.
How do I get this answer each week without opening every project?
A repeatable weekly portfolio answer comes from update reminders, a fixed update format, and the two saved views. Linear's update docs describe reminders sent to the lead, with follow-ups if no update arrives, so each lead posts before your delivery review and both views are current when you open them.
Set it up once:
- In settings, configure project update reminders so they land ahead of your delivery review, and choose where update notifications go; the update docs cover Slack and Inbox notifications.
- Put this format in the project template so every update can be read side by side:
Health: [On Track / At Risk / Off Track]
Cause: [date / scope / blocked work / waiting on client / none]
Evidence: [what in the project shows it]
Owner: [name]
Next step and date: [action] by [date]
Needs from client: [decision, review, or help, or none]
- Before the review, open [Client portfolio: health] and list every At Risk, Off Track, and gray project. Then open [Client portfolio: waiting on client] and note the open client items for each.
- For each flagged project, copy the Cause, Owner, and Next step lines into one portfolio note:
[Client] / [Project]: [health]. Driven by [cause]. Owner [name]. Next: [action] by [date]. Client needs to: [ask or none].
- Spend the meeting on the next steps, not the colors.
Linear's update docs also describe agent-assisted updates, where an agent drafts the update from recent changes and Slack messages. Ask leads to review any draft against the format above before posting it.
What does this approach not tell you?
This approach does not tell you the commercial picture. Health, scope, and issue movement show delivery risk; they do not show margin, contract terms, or how the client feels about the work. A project can be on schedule and still have an unhappy client, so keep your account conversations separate from the Linear review.
The signals are prompts, not verdicts. Some projects add issues late because the team is breaking down work, not because scope grew. The Sentry rules quoted above come only from the summary of its mcpservers.org listing, so adjust any rule you borrow to how your practice delivers. And the method depends on leads labelling client waits consistently; if they don't, the waiting-on-client view will look emptier than it is.
What should I do first?
The first step, before your next delivery review, is small: open Projects, group by health, and ask each lead with an At Risk, Off Track, or gray project for one line on cause, owner, and next step. That gives you a working portfolio answer now, and the setup in the weekly section can follow when you have time.