The daily standup has a dirty secret: nobody gets useful information from it. Engineers recite what they did (which is already in GitHub), what they’ll do (which is already on the board), and blockers (which should have been raised the moment they happened, not 14 hours later at 9:30 AM). Then everyone loses their flow state and doesn’t get it back until lunch.
Async standups fix this by moving the update from a meeting to a written artifact. This guide is the exact system — including the part most guides skip, which is that the best async standup writes itself from your GitHub activity.
Why the standup meeting fails
Three structural problems, none fixable by “making standup more disciplined”:
- It interrupts maker time. A 15-minute meeting at 9:30 destroys the morning’s first deep-work block for every attendee. Research on context switching consistently prices this at far more than the meeting itself.
- The information is already stale or already known. “Yesterday I worked on the auth refactor” — yes, we can see the commits. “Today I’ll continue” — yes, it’s the top card on the board.
- Blockers wait for the meeting. The one genuinely useful standup output is also the one that least needs a meeting. A blocker raised in Slack at 2 PM gets solved at 2 PM. A blocker saved for standup gets solved tomorrow.
The async standup format that actually works
The good async standup has four properties:
- Written, in a durable place — searchable history beats spoken memory.
- On the author’s schedule — post when you start work, in your timezone.
- Anchored to artifacts, not memory — link the PR, the commit, the ticket. Claims age badly; artifacts don’t.
- Blockers get their own channel with real urgency — not a line item in a daily template.
A minimal template per person, per day:
Shipped: <links to merged PRs / commits>
In flight: <link to current work item + % done if useful>
Blocked on: <nothing | link + what you need and from whom>That’s it. If someone writes more than five lines, something’s wrong.
Step-by-step: switching in one week
Day 1 — Pick the channel and the template. One Slack/Discord channel, one pinned template. Announce that Friday’s standup is the last live one.
Day 2 — Run both. People post their async update and attend standup. Feels redundant. That’s the point — it demonstrates how little the meeting adds.
Day 3 — Lead by example. Whoever runs standup posts their update first thing and reacts to others’ posts. Blockers get handled inline, in public, same day.
Day 4 — First fully async day. No meeting. Post by your local 10 AM. The sky will not fall.
Day 5 — Review honestly. What was missing? Usually the answer is “the social bit” — replace it deliberately (a weekly coffee chat) rather than letting it resurrect the daily meeting.
The upgrade: let GitHub write the update for you
Here’s the thing most async-standup guides miss: the template above still asks engineers to remember and type. Two of its three sections are just a summary of what GitHub already knows.
Your repo already records:
- Shipped → merged PRs and commits since yesterday
- In flight → open PRs, recent branch pushes
- Stalled → PRs with no activity in N days, failing CI
So instead of asking people to transcribe their activity, put the activity where the standup is. Two ways to do it:
Option A — the DIY route. A scheduled GitHub Action or Slack workflow that posts each person’s merged PRs and open PRs into the standup channel every morning. Humans only add blockers and context. Works, costs you an afternoon of YAML, and breaks quietly when tokens expire.
Option B — the Kahoona route. Kahoona streams commits, PRs, and CI directly into your project board, next to the tasks they belong to. The “async standup” becomes: open the board, read what actually happened since yesterday, spend five minutes on the two things that are genuinely stuck. Setup is pointing it at your repo — about 30 seconds — and the first project builds itself from your history.
👉 Try Kahoona free — your standup already exists in your repo
Common failure modes (and fixes)
- “Nobody reads the updates.” Your updates are too long or too vague. Anchor to artifacts — a link to a merged PR is readable; a paragraph about “progress on the refactor” isn’t.
- “Updates say ‘working on X’ three days in a row.” That’s not an async problem, that’s a stuck-work problem the meeting was hiding. Good — now it’s visible. Swarm it.
- “Management wants the meeting back.” Give them a dashboard, not a calendar slot. If the board reflects live repo activity, they’ll stop asking.
- “We lost the team bonding.” Real. Replace it on purpose: one weekly social call, and use the time you saved (each person gets back ~4 hours a month) for something that actually bonds.
The bottom line
Async standups work when they’re anchored to artifacts instead of memory. Your GitHub activity is the status update — the only question is whether your team reads it there, or pays a daily meeting to have people recite it from memory.
Start with the template in a Slack channel this week. If you want the updates to write themselves, point Kahoona at your repo and read the board instead — free to start, $5 a seat if it sticks.
Related: Jira shows tickets, not truth · 9 best Jira alternatives for small dev teams