How to do daily standups in a fully async team

Async daily standups replace the live morning meeting with a written daily prompt that every engineer answers on their own clock, with a 24-hour response SLA and a single canonical thread of history. The rule is simple: "I post when I start my day, you respond when you start yours." No live call, no scheduled time, no Zoom link.

This works for fully async teams (zero timezone overlap) because the standup stops being a meeting and starts being a status artifact. Below is the exact workflow we recommend, including the Slack prompt, the escalation path for blockers, and the weekly AI sweep that turns five days of standups into a one-page recap.

Why live standups break the second you go fully async

A live standup assumes everyone is awake at the same time. The moment you have an engineer in Berlin, a PM in San Francisco, and a designer in Jakarta, the only time that works for all three is 11pm somewhere. Three people get tired or quit, and the standup becomes a 20-minute monologue from whoever is still online.

Most teams patch this by going hybrid: live standup for the overlap zone, async update for everyone else. That creates two tiers of engineers. The overlap people get heard; the async people get summarized incorrectly by whoever ran the call.

For a fully async team, that compromise is not available. Either every voice routes through a shared written artifact, or the engineers outside the overlap window get treated as second-class teammates. The async daily standup exists to make the written channel the default for everyone, including the people who could attend a live call.

The shape of an async daily standup that actually works

The format is boring on purpose. Boring formats get answered. Three prompts, posted as a Slack workflow, threaded with the engineer's reply.

1. What did you ship yesterday (link the PR, issue, or doc)
2. What are you working on today
3. Blockers, with priority tag: P0 (stop the world), P1 (need answer in 24h), P2 (FYI)

That is the entire ritual. No "wins of the week," no "how are you feeling," no skip-level questions. Those belong in retros and 1:1s, not in a status thread that needs to be skimmable in 30 seconds.

The Slack workflow fires once per day per engineer, at 9am in their local timezone. The bot pings them. They reply in-thread. The thread auto-archives to a Notion database once the engineer logs off. That is the entire workflow.

The 24-hour response SLA

This is the rule that makes fully async work: any question or blocker posted in a standup gets a written response within 24 hours, from someone on the team. Not the same day, not "by EOD," not "when I get back from the call." 24 hours from post.

The 24-hour clock is enforced two ways. First, a Slack reminder fires on any standup thread with an unanswered blocker after 18 hours. Second, the engineering manager runs a weekly check on standup threads with unanswered blockers and either answers them or reassigns ownership.

What 24 hours buys you is exactly one full async cycle. An engineer in Jakarta posts a blocker at 9am their time. An engineer in San Francisco wakes up 12 hours later, sees it, replies. The Jakarta engineer wakes up the next morning and the answer is waiting. Total elapsed time: 24 hours. Total meetings: zero.

Faster than 24 hours is a P0, and P0s do not go in standups. They get their own incident thread with a paged on-call.

Blocker priority: how to tag and escalate

The single biggest difference between a healthy async standup and a dying one is whether blockers have priority. Without priority tags, every blocker reads as equally urgent, which means none of them feel urgent.

Tag	Meaning	Response expectation	Channel
P0	Production down, customer-impacting, blocking revenue	Page on-call, response in minutes	#incidents
P1	I cannot make progress today without an answer	24-hour written reply	Standup thread + @mention owner
P2	Heads up, will need answer this week	Reply by Friday's sweep	Standup thread

P0 should almost never appear in a standup. If it is genuinely production-down, the engineer pages the on-call rotation, not their PM. Standups are for P1 and P2.

P1 blockers get an @mention of the suspected owner. If the owner is asleep, the next engineer awake either answers or reassigns. P2 blockers get cleared in the Friday sweep, which we'll cover below.

This system collapses the difference between "the founder hasn't answered yet" and "the API is down." Both used to feel like emergencies in chat. Now only one is.

The Slack workflow, configured

Use Slack's built-in Workflow Builder, not a third-party standup bot. The third-party tools (Geekbot, Standuply, Range) all charge per seat and lock your standup history inside their own database, which makes it hard to migrate or search later.

The Slack workflow:

• Trigger: Scheduled, daily at 9am local time per user (Slack respects each user's timezone setting).
• Step 1: Send a DM with three questions.
• Step 2: Post the reply to #standups-eng as a top-level message tagged with the engineer's name.
• Step 3: A Zapier or n8n job picks up the message via the Slack API and appends it to a Notion database row for that day.

Total config time: about 40 minutes. Cost: $0 on Slack's free tier (workflows are included), plus the Zapier free tier or a $20/month n8n hosted instance.

The Notion database is the canonical history. Slack is the surface, Notion is the archive. This matters because Slack's message search is mediocre past 90 days, and Notion gives you a structured table you can filter, tag, and query.

Notion as the canonical standup history

Every standup post syncs to a Notion database with these columns: Date, Engineer, Yesterday, Today, Blockers, Blocker priority, Resolved date, Linked PRs.

A few practical reasons this matters more than it sounds:

• Performance reviews stop being archaeology. When you do a quarterly review, you can filter the database by engineer and see every standup they wrote, every blocker they raised, every PR they linked. No reconstruction from memory.
• Onboarding gets a real corpus. A new engineer can read three weeks of standups in their team's channel and understand what is actually being worked on, in plain language. Better than any onboarding doc you'll write.
• You can find old decisions. "Why did we pick Postgres over MySQL again?" The answer is probably in a standup thread from four months ago. Notion makes it findable.

We've written before about how a structured async standup template becomes the spine of an async engineering team. The daily-cadence rule above is one specific operating mode of that template, designed for teams with zero timezone overlap. For teams with partial overlap (LATAM engineers with US founders, for example), the live-handoff variant in that broader playbook works better.

The Friday AI sweep

This is the trick that makes async standups durable past month two. By Friday at 5pm UTC, an automation runs an AI summary over the week's standup posts and posts a one-page recap to #engineering-weekly.

The prompt:

You are summarizing one week of async standups for an engineering team.
Input: 5 days of standup posts from N engineers (attached as JSON).
Output:
1. What shipped this week (link PRs, group by area)
2. Blockers raised, with current status (resolved / still open / dropped)
3. Patterns to flag: anyone who hasn't posted 2+ days, any blocker open >48h,
   any recurring blocker theme
4. One sentence on momentum vs last week (faster, slower, same)
Keep total under 400 words.

We run this through Claude or GPT-4 via a Vercel cron job. Cost is roughly $0.30 per week per team. The output gets pasted into a Notion page that links back to the standup database.

The Friday sweep is the closest thing fully-async teams have to a status meeting. It takes five minutes to read. It catches the engineer who has been silent for three days because they're stuck and embarrassed to say so. It surfaces the third time this month a deploy blocker has shown up, which is now a project, not a blocker.

If you are running a small async team and need to staff up to make this work end to end, every engineer on Cadence is AI-native by default, vetted on Cursor, Claude Code, and Copilot fluency before they unlock bookings. That AI fluency carries directly into setting up automations like the Friday sweep without needing a separate DevOps hire.

Async standups vs the alternatives

Approach	Live overlap required	Best timezone spread	Tooling cost	Failure mode
Live Zoom standup	Yes, 30 min	0 to 4 hours	$0 (Zoom free tier)	Breaks past 4-hour spread, one person dominates
Hybrid (live for overlap, async update for rest)	Partial	0 to 8 hours	$0 to $50/month standup bot	Two-tier team, async people feel invisible
Async daily standup (this guide)	No	0 to 24 hours	$0 to $20/month (Slack + n8n)	Requires discipline on 24h SLA, blocker priority
No standup, just async PRs	No	Any	$0	Blockers go unsurfaced, no shared status

Be honest about the trade-offs. Live standups are warmer, and a fully async team has to work harder to feel like a team. A monthly all-hands on Zoom (recorded for those who can't make it) plus a quarterly in-person offsite fills that gap better than a daily call ever did.

What to do this week

If you're moving an existing team to async standups, do it in this order:

1. Pick the 9am-local trigger time and the Slack channel. Don't debate it for two weeks. Pick today, change later if needed.
2. Set up the Slack Workflow Builder for the three prompts. 40 minutes.
3. Set up Notion sync via Zapier or n8n. 60 minutes. Skip this if you're a team of 3 or fewer; the Slack history will hold for a quarter.
4. Announce the 24-hour SLA in the channel, in writing. Pin the message.
5. Run it for two weeks. Resist the urge to change the format. Boring on purpose.
6. Add the Friday AI sweep. Two-hour project for an AI-native engineer.

If you don't have someone on the team who can set the AI sweep up, you can book a mid-tier engineer on Cadence at $1,000/week and they'll ship the whole stack (Slack workflow, Notion sync, Friday sweep, Vercel cron) inside the 48-hour free trial. Median time to first commit on the platform is 27 hours.

Where async standups go wrong

Three failure modes we see repeatedly:

• Standup theater. Engineers post "yesterday: PRs, today: more PRs, blockers: none" every day. The fix: the manager has to actually read the standups and reply when they're empty. Once it's clear someone reads them, they get real.
• Blocker rot. P1 blockers go unanswered for a week because no one feels ownership. The fix: every P1 gets an @mention. If you don't know who to @mention, you @mention the EM.
• Channel fatigue. A team of 12 generates 12 standups per day; the channel becomes noise. The fix: use Slack's @here suppression and let engineers mute the channel except for direct mentions. The standup is for the database, not for the live read.

If you're hiring globally to make a fully-async setup work, the best timezone overlap depends on which coast your founders are on, and you can also look at how to onboard a remote engineer in one week so your new hires are productive before they've even attended a meeting (there won't be any).

If you're running a fully async team and you need an engineer who can ship into that setup from day one, every engineer on Cadence is AI-native and async-fluent by baseline. 48-hour free trial, weekly billing, replace any week. Find your engineer in 2 minutes.

FAQ

How often should we run async standups?

Daily, Monday through Friday. Skipping days breaks the rhythm and lets blockers pile up. A daily prompt that takes 90 seconds to answer is better than a weekly summary that takes 20 minutes to write.

What if an engineer doesn't post for a day?

Slack should auto-reminder them at 12pm local time. If they miss two days in a row, the EM DMs them directly. Three days is a conversation, not a Slack reminder. Most missed standups are signal: stuck, burnt out, or interviewing.

Do async standups work for teams of 20+?

Yes, but split the standup channel by squad once you cross 8 engineers per channel. One firehose of 20 standups per day is unreadable. Four squad channels of 5 standups each, with a weekly cross-squad summary, scales to 50+ engineers.

What if our founder wants a live call?

Run the live call as a weekly 30-minute "demo and decisions" session, not a daily standup. Founders want visibility into momentum and unblocking. The async standup gives them the momentum signal in writing; the weekly call gives them the human one.

How do we handle on-call rotations and incidents in this setup?

Incidents are not standups. P0 issues page the on-call rotation through PagerDuty or Opsgenie. The standup mentions yesterday's incident as a one-liner ("on-call from 2am to 4am, root cause was rate limiter, postmortem in Notion") but the incident itself never lives in the standup channel.