Async standups: how to run daily check-ins without a meeting

An async standup asks the same three questions a synchronous one does — what did you finish, what are you doing today, what's blocking you — and gets the same answer in writing, posted by a deadline instead of spoken in a room at a fixed time. The trade is straightforward: you give up the real-time back-and-forth of a live meeting in exchange for zero calendar cost and a written record that doesn't evaporate the moment the meeting ends. Whether that trade is worth it depends entirely on what your team's standup was actually accomplishing.

What a standup is actually for

The standup's original job is narrow: surface blockers fast, so they get unstuck instead of festering silently until the next planning meeting. It was never supposed to be a status report delivered to a manager, and the moment it becomes one — everyone reciting their tasks to a room that's only half listening — it's stopped doing its job regardless of whether it's sync or async. That distinction matters here because switching formats doesn't fix a standup that's already become theater; it just changes what the theater looks like.

Why sync standups strain at scale or across time zones

A daily 9am sync works cleanly for a co-located team of six. It gets expensive fast once a team spans time zones — someone is always joining at 7am or staying past dinner, and the meeting either shrinks to accommodate the smallest common window or quietly excludes whoever can't make it. Even without time zones, a standup that's grown past eight or nine people tends to become a report delivered to the group rather than a conversation, because most of what's said doesn't apply to most of the people in the room. Neither of these is really a scheduling problem — they're signs the format has outgrown what a fifteen-minute sync meeting can efficiently do.

The async format that actually works

The version that holds up: each person posts done / doing / blocked once a day, by a fixed deadline (not a fixed time — 'before 11am your time' beats 'at 9am' for a distributed team), and — this is the part that's easy to skip — the update lives on the actual issue it's about, not in a separate standup channel that exists nowhere near the work. A blocker mentioned in a Slack thread that nobody links back to the issue is a blocker that's easy to lose; a blocker posted as a comment on the issue itself is visible to anyone who opens that issue later, which is a much larger audience than whoever happened to be scrolling the channel that morning.

Keep the questions to three and resist the pull to add more. An async format that asks for done/doing/blocked plus mood, plus goals for the week, plus anything else, turns into homework people start skipping, and a standup nobody actually fills out is worse than no standup — it creates a false sense that blockers are being surfaced when they aren't.

Where async breaks down

Async is for surfacing that a blocker exists, not for resolving one that needs real debate. If someone posts 'blocked: unclear whether we should use approach A or B,' that's a decision that needs a live conversation, not four more asynchronous comments spread across a day. The right move is to use the async update as the trigger — it flags that a sync conversation is needed — rather than trying to force the resolution itself into writing. Teams that try to negotiate a genuine disagreement entirely in comments usually take longer and end up scheduling the call anyway, just a day later than they should have.

What the update actually looks like

In practice it's short: 'Done: shipped the export fix (ENG-412), reviewed ENG-430. Doing: starting on the pagination bug. Blocked: nothing.' Three lines, thirty seconds, and every noun in it is a real issue someone can click through to. Compare that to a synchronous version of the same update, delivered out loud to eight people who mostly weren't working on the export fix and don't need to hear about it in real time — the async version isn't less information, it's the same information routed only to the people who'll actually go looking for it, which is most of what a large synchronous standup wastes.

Keeping it honest

The failure mode specific to async is that silence is ambiguous. In a sync standup, someone not speaking up is visible in the room; in an async one, a missing update looks the same whether someone is quietly stuck or just didn't post. The fix isn't more process, it's visibility: if updates are attached to issues, a stalled issue with no recent comment is itself a signal, independent of whether anyone remembered to post a formal update that day. That's the case for tying standups to the work item rather than a separate log — the record and the reality stay attached to each other.

If writing the same three-line update every day is the friction that kills adoption, the standup generator drafts one from what actually moved on your issues, so the update is a thirty-second edit instead of a blank box. And the same discipline that makes async standups useful — routing signal to the right place without a meeting — is what AI triage does for inbound requests before anyone has to sort them by hand.