How to write standup updates that actually get read

Illustrated scene of a team of stylized characters each at their own desk, some ignoring chat messages while others engage with concise, highlighted updatesIllustrated scene of a team of stylized characters each at their own desk, some ignoring chat messages while others engage with concise, highlighted updates 87% of agile teams run daily standups, yet 92% of people admit to multitasking during virtual meetings. Async standups fix the scheduling problem, but they introduce a new one: if nobody reads your update, you wasted your time writing it. What separates updates people skim from updates people act on is mostly just writing habits.

Write the delta, not the diary

Your team does not need a recap of everything on your plate. They need to know what changed since yesterday.
Instead of thisWrite this
"Working on the API""Finished auth token refresh (PROJ-142). Starting rate limiting today, PR by EOD."
"Had some issues yesterday""Blocked on staging deploy — CI failing on Docker build. Posted in #devops, waiting on Sarah."
"Continued work on the feature""Search indexing is done. Starting result ranking, should be testable by tomorrow."
If your update could have been copy-pasted from yesterday, it is not saying anything.

Keep it scannable

Your teammates are scanning five, ten, maybe twenty updates. They will not read paragraphs. Target 3 to 5 bullet points, one sentence each. If your update takes longer than 10 seconds to read, trim it. A good structure:
  • Done: One or two completed items with ticket numbers
  • Today: What you are focusing on, with enough detail that someone could tell if you need help
  • Blocked: Only if genuinely stuck. Tag the person, state what you need, give a deadline
Skip anything that only matters to you. If it is only relevant to one other person, send a DM instead. Illustrated split view comparing a cluttered wall of text standup update on the left versus a clean, structured three-bullet update on the rightIllustrated split view comparing a cluttered wall of text standup update on the left versus a clean, structured three-bullet update on the right

Blockers need to be loud

The most common failure in async standups is the buried blocker. Someone writes three paragraphs about their progress and tacks on "also might need database access at some point" at the end. Nobody notices. The writer assumes someone will help. Nobody does. If you are blocked, lead with it. Use a visual signal your team agrees on — bold text, a tag, an emoji. Then follow a simple formula:
  • What is the obstacle (be specific)
  • Who can unblock you (tag them by name)
  • When you need it resolved
Bad: "Blocked on some permissions stuff." Good: "[BLOCKED] Need write access to analytics-prod S3 bucket for the reporting pipeline. @Maria, can you submit the IAM request? Blocking Tuesday's release if not resolved by Monday EOD." And when a blocker gets resolved, say so publicly. "Unblocked on S3 access, thanks @Maria. Deploying today." This closes the loop and shows the team that raising blockers in standup actually gets results.

Connect work to outcomes

The best updates explain why the work matters, not just what it is. Instead of "Refactored the user service," write "Refactored user service to fix the N+1 query causing 3-second load times on the dashboard." The second version gives readers a reason to remember it. You do not need to do this for every line item. But for the main thing you shipped or the main thing you are working on, one extra clause turns a task into context.

The anti-patterns

If you recognize yourself in any of these, you know what to fix. The laundry list: "Fixed a bug. Updated docs. Had a meeting. Reviewed a PR. Updated dependencies." This lists activities but communicates nothing about outcomes. The technobabble dump: "Spent yesterday debugging the race condition in the mutex lock acquisition path for the distributed cache invalidation layer..." Nobody needs this in a standup. Save it for the PR description. The non-update: "Yesterday: worked on stuff. Today: continue. Blockers: none." This trains your entire team to skip your name. The status report: "Velocity is tracking at 80% of planned capacity. Burndown shows we are on track." This is for sprint review, not standup. Standups are about coordination, not reporting. Illustrated birds-eye view of a diverse team collaborating through floating message cards connected by dotted lines across a stylized mapIllustrated birds-eye view of a diverse team collaborating through floating message cards connected by dotted lines across a stylized map

Make it a habit, not a chore

The best standup updates take 60 seconds to write — if you prepare. Before posting, spend a moment reviewing what you actually did. Check your git history, your ticket board, your calendar. Then write 3 bullets and move on. Tools like Kollabe's async standup feature make this easier with structured prompts, the ability to load yesterday's submission as a starting point, and daily organization so your team can scan updates without digging through chat. AI summaries pull out blockers and recurring patterns automatically, so even when people skim, the important stuff still gets noticed.

3 to 5 bullet points, one sentence each. If it takes longer than 10 seconds to read, it is too long. Write the delta — what changed — not a full status report.

Yes, but only if the team can act on them. If you need something from a specific person, tag them and state the deadline. If your laptop is broken, tell IT, not standup.

Start by reacting to other people's updates. Acknowledgment breaks the "nobody reads these" cycle. Write shorter, more specific updates and lead with blockers so people learn that your updates contain actionable info.

For distributed teams, usually yes. They eliminate scheduling conflicts and let people write updates when they are most focused. For co-located teams, a quick live sync can still work — but the writing principles are the same.
Last Updated on 09/02/2026