How to Write Project Updates in Linear (Health, Cadence, and Format)
Status reporting is one of the least loved and most important parts of a PM's job. When it lives in a separate doc or a Slack thread, it drifts away from the work and nobody trusts it. Linear's project updates put status next to the issues it describes, with a health indicator that makes risk visible at a glance.
This guide covers how to post project updates in Linear, how to set a cadence with reminders, what to write in each update, and how to route updates to stakeholders who never open Linear. The goal is a weekly habit that takes ten minutes and gives leadership an honest picture.
Working in Linear? Turn your spec into dependency-ordered tickets.
Paste the feature or spec. Vantage pulls out the requirements and breaks them into tickets, ordered by what blocks what, ready to groom with your team.
How this works
- We save what you typed. No AI runs on this page.
- You create a free account.
- Vantage builds a PRD and dependency-ordered tickets from it inside your own workspace.
Why ask for an account? We’re a small team, and a full generation runs a multi-step AI pipeline that costs us real money. So we tie it to a free account instead of running it anonymously. You also get to keep the result and edit it.
Your text is only used to create your project, and it stays private to your account. If you don’t sign up, we delete it after 7 days. Privacy policy
Step-by-step guide
Assign a project lead
Every project should have a lead, the person responsible for posting updates. Without a named lead, updates become a shared chore that nobody does. Set the lead in the project's properties. For cross-functional projects, the PM is usually the lead, but an engineering lead can own updates for technical projects.
- Open the project and set the Lead property
- Confirm the lead knows they own the update cadence
- Add the relevant teams and members to the project
Set an update cadence and reminders
Linear can remind project leads to post updates on a regular schedule. Configure the reminder cadence in settings so leads get a nudge on the same day each week. Weekly is right for most active projects; biweekly can work for long-running projects with slower change. Consistency matters more than frequency.
Choose the right health status
Each update carries a health status: On track, At risk, or Off track. Be honest and specific. On track means you expect to hit the target date with current scope. At risk means something could cause a slip and you have a plan to address it. Off track means the date or scope will change. Defaulting to 'On track' until the week before launch destroys the value of the signal.
- Compare current progress to the target date and remaining scope
- Mark At risk as soon as a credible threat to the date appears
- Mark Off track when you know the date or scope must change
- Explain the reason for any change in health in the first sentence
Write the update in a consistent format
Use the same structure every week so readers know where to look. A format that works: one-line summary, what shipped since the last update, what is next, risks and asks. Link to specific issues rather than describing them. Keep it under 200 words; if you need more, the project probably needs a meeting.
- Start with a one-sentence summary that matches the health status
- List what shipped since the last update with issue links
- List what is planned next
- Call out risks and any decision or help you need, with an owner
Use initiative updates for the bigger picture
If your projects roll up into initiatives, initiative updates summarize health across multiple projects. Leadership often reads initiative updates and drills into project updates only where something is at risk. Write initiative updates after project updates so you can reference them.
Route updates to Slack
Many stakeholders never open Linear. Linear's Slack integration can post project updates to a channel so they reach people where they already read. Create a channel per initiative or product area, and configure the project to post updates there. Ask stakeholders to reply in thread rather than DM so the discussion stays visible.
Review update history in planning
Update history is a record of how the project actually went. Before quarterly planning or a retro, read through a project's updates. Patterns such as repeated 'At risk' because of the same dependency are the most useful input for improving how you plan the next project.
Common mistakes
Watermelon status
Green on the outside, red inside. Marking a project On track while the team knows it is slipping erodes trust in every future update. Flag risk early; it is cheaper than surprising people later.
Writing activity instead of progress
'We had three meetings and reviewed designs' is activity. 'Checkout redesign is in QA; payment retry is blocked on API' is progress. Report outcomes and blockers.
Skipping updates when nothing changed
A quiet week is still information. Post a short update confirming the status so readers know the project has not been forgotten.
Tips
Write updates at the same time each week, ideally after standup, while details are fresh.
Name the person who needs to act on each ask, not just the team.
Link the PRD in the project description so readers of updates can find context quickly.
Keep a short running list of risks in the project description and reference it in updates.
How Vantage helps
Project updates are easier to write when you can see how shipped tickets map back to requirements. Vantage keeps PRD requirements linked to the tickets it pushes to Linear, and bi-directional sync brings status changes back into the spec, so you can see which requirements are done and which are at risk before you write the update.