“Async Standups: How to Replace Daily Meetings”

What is an async standup, and what does it replace?

An async standup is a written status update that replaces the live daily meeting. Each person answers the same short set of questions in a channel or tool, at a time that suits their own working day, and everyone reads the thread when their day starts.

It replaces the sync ceremony, not the purpose. The purpose of a daily standup is shared awareness and fast unblocking. A written update does shared awareness better, because it is searchable and permanent. It does unblocking worse, because nothing forces a response. That asymmetry is the whole design problem, and most failed async standups are attempts to solve it by hoping.

Three variants are common, and they are not equivalent:

GitLab, which publishes its own async practices, uses the bot approach internally and documents a manual version as well: an issue titled “Stand-up”, a comment per day, and each person replying in the thread. That combination, a channel for the daily scan plus comments on the work item for anything that matters, is the most durable pattern. The channel answers “where is everyone”, the ticket answers “what is happening with this”.

Do async standups actually save time?

Less than the pitch suggests, and more than the arithmetic suggests. A 15-minute meeting with nine people consumes 135 person-minutes, or 2.25 hours, every day. Over 22 working days that is 49.5 hours a month. An async equivalent at six minutes to write and five to read is 99 person-minutes a day, or 36.3 hours a month. The saving is about 13 hours a month across the team, roughly a third of a working week.

Thirteen hours is not the real prize. The real prize is the interruption. Attention research from Gloria Mark’s work at UC Irvine puts the cost of returning to a task after an interruption at more than 20 minutes. Nine people pulled out of deep work at 09:30 do not lose fifteen minutes; they lose the half hour before and the twenty minutes after.

The honest trade-off: async costs discipline and returns focus. If your team does not read, the meeting was doing the reading for them, badly but reliably.

What should each update actually contain?

Keep it to four lines: what moved, what is next, what is blocked, and what was decided. Anything longer becomes a journal, and journals stop being read by the third week.

A workable template:

> Shipped: export fix merged (ENG-412); reviewed the pagination PR. > Next: start the retry logic; 2 hours on the vendor call. > Blocked: waiting on staging credentials from DevOps since Tuesday. > Decision: we are going with cursor pagination, not offset. Logged in ADR-14.

Four lines, about 60 words, all of it verifiable. Compare that with the version that gets ignored: “Working on the export stuff, making good progress, will continue tomorrow.” The second contains no information a reader can act on, and it is the natural output of a prompt that asks “what are you working on”.

Three rules make the difference:

1. Outcomes, not activity. “Merged PR 412” beats “worked on the export feature”. If nothing shipped, say what moved and by how much.
2. Every noun is clickable. Link the ticket, the document, the pull request. A reader in another time zone cannot ask you what you meant.
3. Blockers get their own line and a name. “Waiting on DevOps” is a complaint. “Waiting on staging credentials from @maria since Tuesday, needed by Thursday” is a request.

> Common mistake: asking for mood, wins of the week, and long-term goals in the same daily prompt. Every added field reduces the completion rate. Move those questions to the weekly review or the retrospective, where they belong.

How do you set a deadline across time zones?

Set the deadline relative to each person’s own morning, and define one overlap window for anything that needs conversation. A single global deadline is the most common reason async standups die in distributed teams.

Here is why. A 09:00 UTC standup lands at 10:00 in Berlin, 18:00 in Tokyo, 22:00 in Auckland, and 04:00 in New York. Four of those five are unreasonable, and the people at the edges either post stale updates or stop posting.

The fix is a per-person rule rather than a team-wide hour: post within the first hour of your own working day, and read the thread before your first meeting. That gives a rolling handover rather than a synchronized snapshot. Auckland posts at 08:00 local, which is 19:00 UTC the previous day; San Francisco reads it at 08:00 local, which is 16:00 UTC. The information is twelve hours old and still useful, which is the point.

Then add one overlap window a week, 60 minutes, for conversations writing cannot carry. Teams that skip it end up scheduling ad hoc calls anyway, usually at the worst possible hour for someone.

If you need a single deadline, make it “before your local noon” and accept that the thread is a rolling document rather than a morning briefing.

How do you make blockers actually get resolved?

Give every blocker an owner, a response time, and a tag. A blocker without those three is a sentence, not an action.

The escalation rule that works in practice has three levels:

• P1: cannot progress today. Needs a written response within 24 hours, with an @mention to the person who can unblock it.
• P2: will need an answer this week. Reply by the Friday review.
• P0: production down or customer-impacting. Does not belong in a standup at all. Page the on-call and open an incident thread.

Twenty-four hours sounds slow until you count the cycle. Someone in Jakarta posts a P1 at 09:00 local. A colleague in San Francisco wakes twelve hours later, sees it, and answers. The answer is waiting when Jakarta starts again. Total elapsed: 24 hours, zero meetings. A 24-hour standard is what makes a fully async cycle possible; a same-day standard quietly forces everyone into overlapping hours.

Name a triager. One person, rotating weekly, whose first job of the day is to read every post and respond to each blocker, either with an answer or with an escalation. This is the single highest-leverage role in an async standup, and it is the one most teams forget to assign. Without it, “someone will pick it up” is the process.

Two supporting habits: tag the person who can unblock, not the channel; and keep a weekly sweep of unresolved blockers, which takes ten minutes and catches everything the daily thread let slide.

How do you switch from a live standup without losing the habit?

Run a four-week transition, keep the old meeting as a fallback for two of those weeks, and measure three things before you commit.

Week 1: run both. Keep the 15-minute call and add the written update. It is redundant and slightly annoying, which is the point: people learn the format while the safety net is still there.

Week 2: written first, call optional. The call becomes a 10-minute slot for blockers only. Anyone with no blocker does not need to attend.

Week 3: written only, with a triager. Cancel the call. Watch what happens to blockers; this is the week the format either works or quietly dies.

Week 4: review and adjust. Check three numbers: average age of open blockers, share of updates posted by the local deadline, and average update length. If blocker age rose and read rate fell, the problem is escalation, not format.

The metrics that tell you it is working are unglamorous:

A realistic first-quarter improvement, based on how teams typically run this: median blocker age falls from around two working days to under one, because a written blocker is visible to everyone rather than to the eight people in the room. That is the outcome worth measuring, not the minutes saved.

Which tool setup is least likely to fail?

Use what the team already opens, and keep the archive searchable. A bot that prompts in Slack or Teams and posts answers to a channel is the lowest-friction option for most teams, because the prompt solves the “I forgot” problem and the channel solves the “where was that” problem.

Three setups, in order of effort:

1. A bot in chat. Apps such as Geekbot or Dailybot send the prompts at each person’s local time, collect answers, and publish them to a channel. Geekbot, for example, supports per-user time zones and lets people answer later without a hard expiry.
2. A manual channel thread. One thread per day, started by the same person at the same hour, with a pinned template. Zero cost, works everywhere, depends on discipline.
3. Issue comments. The update lives on the task. Best for traceability, worst for a quick morning scan.

Whichever you pick, keep two channels of record: the daily thread for scanning, and the task for detail. When a blocker is resolved, write the resolution where the work lives, or the next person to open the ticket sees a problem that was solved a week ago.

When does an async standup fail?

It fails in four predictable situations: a brand-new team, an active incident, unclear ownership, and leaders who do not read.

A new team. People who have never worked together cannot infer context from four lines. For the first month, a short live session builds the shared model that writing later relies on.

An active incident. Async is for status, not for negotiation. If a decision needs four people to disagree productively, a thread will take a day and end in a call anyway, one day later than necessary. Use the written update as the trigger for the call.

Unclear ownership. If nobody knows who owns the work, a written update exposes that faster but does not fix it. Async assumes tasks have owners and dates; without them, the thread becomes a list of intentions.

Leaders who do not read. This is the most common cause of death. If the manager posts and leaves, the team learns that posting is a ritual performed for an audience of nobody. Reading is the leadership behaviour that makes the format work, and it takes ten minutes a day.

The honest trade-off: async standups buy focus and time-zone coverage, and they cost immediacy and warmth. Teams that need rapid back-and-forth, or that are still building trust, should keep a short live check-in and use writing for everything else.

How does Doitify support an async standup?

Doitify supports the work the standup describes, which is where most of the value sits. Tasks and sub-tasks carry owners, due dates, checklists, and status, so an update can point at something real instead of describing it. Comments keep the discussion on the task, reminders keep the deadline visible, work and performance reports show what actually moved, and team chat handles the coordination that does not belong in a status thread.

The practical benefit is one source of truth. A written standup that links to tasks in the same workspace gives you a daily record and a project record that agree with each other. Doitify is our product, so weigh that accordingly: if your team already has a task tool everyone opens, the standup format matters far more than the platform underneath it.

Conclusion

An async standup is not a meeting that moved into a text box. It is a small operating system: three prompts, a local deadline, a triager, a response standard, and a weekly window for the conversations that writing cannot carry.

Build those five parts and the format holds. Skip the escalation rules and you have replaced a meeting nobody loved with a channel nobody reads.

Start with four weeks, keep the old meeting as a fallback for two of them, and judge the result on blocker age rather than on minutes saved. If blockers move faster and the team stops losing its mornings, the meeting has done its job and can go.

If this post on async standup was helpful, you might also enjoy How to Manage Multiple Projects at Once: 9 Tips and Burndown vs Burnup Chart: Key Differences, Pros and Cons, and When to Use Each.