What is an async standup?
An async standup is a daily status check-in where team members post updates on their own schedule instead of meeting live (typically through a tool like Slack) with responses feeding directly into the team's task tracker. This guide covers formats, tooling, and how to keep async stand-ups from becoming just another ignored channel.
Catapult Labs is an Atlassian Marketplace Partner (Silver tier) and the team behind Agile Retrospectives for Jira, ScrumPoker Estimates for Jira, and StandBot.
An async standup replaces the live, synchronous "everyone on a call at 9am" format with a rolling check-in: each person posts their update whenever their workday starts, and the rest of the team reads it whenever theirs does. No one has to be awake at the same time for status to move.
That distinction matters more than it sounds like it should. A standup's job was never really "the meeting"; it's the status update and the blocker surfacing. Async formats keep both jobs and drop the part that was only ever a scheduling compromise: getting everyone in the same room (or call) at the same time.
The math against live stand-ups gets worse the more spread out a team is. Research cited by distributed-team consultancies points to Harvard Business School analysis finding that losing just one hour of timezone overlap reduces synchronous communication between team members by roughly 19%. Spread a team across three or four timezones and the "everyone's awake and available" window shrinks fast; sometimes to nothing.
Even inside a single timezone, live stand-ups have a way of drifting. What starts as a 10-minute status round becomes a 25-minute discussion, because the room is already assembled and someone always has "one more thing." Async formats remove that gravitational pull by design: there's no room to linger in.
None of this means live meetings are bad. It means using a live meeting for something that doesn't need to be live (reading out yesterday's ticket updates) is an expensive way to solve a problem async formats solve for free.
Not every async format works equally well. The ones that hold up over time share a few traits: they're short, they're specific, and they make it obvious when someone needs help.
The three-question format is the baseline for a reason:
The "blockers first" variant flips the order (blockers, then in-progress, then done) so the thing that actually needs a response from someone else doesn't get buried at the bottom of a message nobody finishes reading.
The Jira-linked format ties each line item to an actual ticket key instead of a prose description: "JIRA-482: code review done, waiting on QA" instead of "finished the thing, waiting on testing." This is the format that actually pays off later, because it's the one a tool (or a teammate skimming fast) can parse without translation.
Cadence matters as much as format. Daily is standard for active sprints; some distributed teams drop to three times a week for steady-state maintenance work, reserving daily check-ins for crunch periods. The wrong move is running daily stand-ups out of habit long after the team's actual coordination needs have dropped.
This is the part worth being careful about. The temptation with any async format is to automate the whole thing: auto-summarize, auto-flag, auto-close the loop. That's a mistake if it means the actual human update disappears.
The useful automation is narrower: getting status out of a chat channel and into the system where the work already lives, without changing what a person actually writes. StandBot runs the daily check-in asynchronously in Slack and writes each person's update straight back to the relevant Jira issue; so the status update a person types once shows up on the ticket automatically, instead of living only in a channel that scrolls away. Blockers surface the moment someone posts them, not the next time someone happens to scroll up.
What that isn't: an AI writing the update for someone based on their commit history or ticket activity. The person still says, in their own words, what's blocking them. The automation just makes sure that sentence ends up somewhere useful instead of evaporating into Slack history.
Async stand-ups surface blockers in real time. Retrospectives are where the team asks "why did that keep happening?" The two ceremonies work better paired than isolated: a blocker that shows up in three consecutive Standups is exactly the kind of pattern a retro should catch, but only if someone's tracking it across days instead of relying on memory.
Pairing StandBot's async check-ins with Agile Retrospectives for Jira closes that loop: standup blockers are already logged against real tickets, so when retro time comes around, the team is looking at actual data instead of reconstructing the sprint from memory.
A few patterns show up over and over in teams that try async stand-ups and quietly abandon them:
If your team is still running live stand-ups purely out of habit, this is usually an easy switch to test: StandBot works inside Slack, has no separate dashboard to check, and writes straight back into Jira.