How to Write a Standup Async Update in English

Learn the English structure for a written async standup update: what you did, what's next, and what's blocking you, written for a remote or distributed team.

An async standup update replaces the live meeting for distributed teams working across time zones, and it only works if it’s specific enough that a teammate reading it eight hours later actually understands your status — not just a vague “working on the feature, all good.”

Key Vocabulary

Yesterday / today / blockers — the standard three-part structure of a standup update: what was completed, what’s planned next, and anything preventing progress, kept concise but specific. “Yesterday: finished the API endpoint and wrote tests. Today: starting on the frontend integration. Blockers: none currently, but I’ll need design sign-off before I can finalize the UI.”

Blocker — a specific, named obstacle preventing progress, distinct from a general difficulty; a good blocker statement identifies exactly who or what needs to act to unblock it. “Blocker: waiting on the staging database credentials from the platform team — requested yesterday, following up today if I don’t hear back by noon.”

Status marker (on track / at risk / blocked) — an explicit, glanceable indicator of whether a task is progressing as expected, letting teammates skim many updates quickly without reading every line closely. “Status: at risk. The task is more complex than estimated — I’ll have a clearer timeline by tomorrow, but wanted to flag it early rather than surprise anyone at the deadline.”

Carryover — work that was planned for a previous update but not completed, explicitly acknowledged rather than silently re-listed as if it were new. “Carryover from yesterday: the migration script is still in progress — underestimated the edge cases in the data, about 70% done now.”

Common Phrases

  • “Yesterday: [specific completed work]. Today: [specific planned work]. Blockers: [specific obstacle or none].”
  • “Status: on track / at risk / blocked — flagging early so there’s no surprise later.”
  • “Carryover from yesterday’s update: still working on X, here’s the current state.”
  • “Blocked on [specific person/team] for [specific thing] — following up [when].”
  • “No blockers currently, but flagging a dependency on X landing before I can start Y.”

Example Sentences

A clear, specific async update: “Yesterday: shipped the rate-limiting middleware and got it through review. Today: starting on the retry logic for the client SDK. Blockers: none. Status: on track for Thursday’s demo.”

Flagging a blocker with a clear ask: “Blocker: I need the updated API contract from the mobile team before I can finalize the response schema. Pinged them yesterday, no response yet — will escalate in standup channel if I don’t hear back by end of day.”

Reporting carryover honestly: “Carryover: the data migration is taking longer than estimated due to unexpected null values in legacy records. About 60% through, revised estimate is end of week rather than yesterday’s original target.”

Professional Tips

  • Keep the yesterday/today/blockers structure specific, not generic — “worked on the feature” tells a remote teammate nothing useful; “finished the validation logic, starting on error handling” does.
  • Name a blocker with exactly who or what needs to act — a vague “blocked” without a named dependency leaves teammates unsure whether they can help.
  • Use a status marker proactively when something is at risk, rather than waiting until the deadline to surprise everyone — flagging early is always better received than flagging late.
  • Acknowledge carryover honestly instead of silently re-listing yesterday’s task as if it’s new — it builds trust in your updates and gives teammates an accurate read on actual progress.

Practice Exercise

  1. Write a yesterday/today/blockers update for a hypothetical task.
  2. Write a blocker statement that names a specific person or team to unblock it.
  3. Write a carryover update acknowledging a task took longer than expected.