Remote engineering team async standup template

An async standup template is a daily message format your engineers post in a shared channel, replacing the live morning call. The minimum viable version is three lines: yesterday, today, blockers. Below are five copy-pasteable templates (basic, Linear-integrated, blocker-heavy, retro-mixed, weekly summary) with filled-in examples for a typical Tuesday, Wednesday, and Thursday cycle.

If you want the full playbook on why async standups beat live ones and how to roll them out, read our guide to running async standups for engineering teams. This post is templates only.

How to use the templates

Each template below assumes the same operating model: one Slack (or Discord, or Linear) channel, a posting deadline (we recommend the engineer's local 11:00), and a thread for follow-ups. The post itself stays short. Discussion happens in the thread so the channel scans cleanly.

Pick one template and run it for two weeks before changing anything. The cost of switching formats every Monday is higher than the cost of using a slightly-wrong format consistently.

When to use which template

Template	Use when	Team size	Tooling required	Posting time
1. Basic Y/T/B	Brand new to async; under 6 engineers	2 to 6	Slack channel	3 minutes
2. Linear-integrated	Issues live in Linear and you want status auto-attached	Any	Slack + Linear	2 minutes
3. Blocker-heavy	Team is shipping fast but unblocking is slow	4 to 12	Slack channel	4 minutes
4. Retro-mixed	You want continuous improvement without a separate weekly retro	3 to 10	Slack + Notion	5 minutes
5. Weekly summary	You also want a Friday rollup for leadership	Any	Slack + Notion or Linear	5 minutes Friday only

The picker in one sentence: start with template 1 for two weeks, graduate to template 2 once Linear is your source of truth, add template 4 if your weekly retro feels like overhead, and bolt on template 5 the day a non-engineer asks you "what shipped this week".

Template 1: Basic Y/T/B (yesterday, today, blockers)

This is the format Scrum gave us, ported to text. It works because everyone already knows the shape, which means the team doesn't argue about the format and just posts.

*Standup - [Day, Date]*
Yesterday:
- [What you shipped or completed]
- [What you spent time on]
Today:
- [What you're shipping next]
- [Other meaningful work]
Blockers:
- [Anything stopping you, or "none"]

Filled-in example: Tuesday

*Standup - Tue, May 19*
Yesterday:
- Shipped Stripe webhook retry logic (PR #1247, merged)
- Wrote ADR for moving billing events to Inngest
Today:
- Wire Inngest into the billing pipeline behind a feature flag
- Review Maria's PR on the invoice PDF generator
Blockers:
- None

Filled-in example: Wednesday

*Standup - Wed, May 20*
Yesterday:
- Inngest integration behind flag, dual-write working in staging
- Reviewed Maria's invoice PDF PR (left 4 comments)
Today:
- Flip flag in staging, monitor for 24h
- Pair with Jin on the failed-payment email
Blockers:
- Need an Inngest production API key (asked Dev in #infra)

Filled-in example: Thursday

*Standup - Thu, May 21*
Yesterday:
- Inngest stable in staging, zero diverged events
- Paired with Jin, failed-payment email shipped
Today:
- Prod rollout for Inngest at 10% traffic
- Start on the customer portal subscription cancel flow
Blockers:
- None (Dev rotated the API key yesterday)

Notice the blocker line resolves between Wednesday and Thursday. That is the entire point of the format. If a blocker stays open three days in a row, the manager pings in-thread instead of waiting for the next standup.

Template 2: Linear-integrated

If your work lives in Linear (or Jira, or GitHub Issues), force the standup to reference issue IDs. This kills the "what did I actually do yesterday" problem because the engineer copies the issue numbers from their Linear "Done this cycle" view.

*Standup - [Day, Date]*
Shipped:
- [LIN-1234] [Issue title] - [merged/closed]
- [LIN-1235] [Issue title] - [merged/closed]
In progress:
- [LIN-1240] [Issue title] - [% done or current state]
- [LIN-1241] [Issue title] - [% done or current state]
Blockers / asks:
- [Issue or person you need]

Filled-in example: Tuesday

*Standup - Tue, May 19*
Shipped:
- [LIN-4421] Stripe webhook retry - merged
- [LIN-4429] ADR: move billing to Inngest - closed
In progress:
- [LIN-4430] Inngest billing wire-up - 30%, branch pushed
Blockers / asks:
- None

Filled-in example: Wednesday

*Standup - Wed, May 20*
Shipped:
- [LIN-4432] Invoice PDF review pass - comments left
In progress:
- [LIN-4430] Inngest billing wire-up - 70%, staging dual-write live
- [LIN-4435] Failed-payment email - pairing with Jin this afternoon
Blockers / asks:
- @dev: production Inngest API key

Filled-in example: Thursday

*Standup - Thu, May 21*
Shipped:
- [LIN-4435] Failed-payment email - merged
In progress:
- [LIN-4430] Inngest billing - 10% prod rollout running
- [LIN-4441] Customer portal cancel flow - started, scoping doc in Notion
Blockers / asks:
- None

The advantage of this format is that every line is a link. Anyone reading can click into Linear and see the actual diff, the assignee, the labels. The standup becomes a routing table, not a status report.

Template 3: Blocker-heavy

Use this when your team is shipping individually but unblocking each other is the bottleneck. The format inverts the priority: blockers go first, work goes second.

*Standup - [Day, Date]*
🚧 BLOCKERS (read first):
- [Specific blocker], need [specific person or decision] by [time]
- [Or "none"]
Shipped since last standup:
- [Brief]
On today:
- [Brief]

Filled-in example: Tuesday

*Standup - Tue, May 19*
🚧 BLOCKERS (read first):
- Need product decision on whether annual plans get prorated refunds. @sara by EOD.
- Need DNS record for billing.example.com. @ops by 2pm PT.
Shipped since last standup:
- Webhook retry logic
On today:
- Inngest wire-up
- Invoice PDF review

Filled-in example: Wednesday

*Standup - Wed, May 20*
🚧 BLOCKERS (read first):
- Inngest production API key. @dev, ETA?
- Annual refund question still open. @sara
Shipped since last standup:
- Inngest staging dual-write
On today:
- Failed-payment email pairing
- Wait on prod key, will pick up portal work in the meantime

Filled-in example: Thursday

*Standup - Thu, May 21*
🚧 BLOCKERS (read first):
- None.
Shipped since last standup:
- Failed-payment email merged
- Inngest API key rotated, prod ready
On today:
- 10% Inngest prod rollout
- Portal cancel flow

Two things about this format: the emoji is functional, not decorative (it makes the section scannable in a busy channel), and the "by [time]" on every blocker forces an SLA. If the blocker has no time, it gets ignored. We learned this the hard way running remote engineering teams that cost a fraction of in-office and where every hour of someone-waiting compounds.

Template 4: Retro-mixed

Most teams run a separate weekly retro. The retro-mixed standup folds retro signal into the daily post, so by Friday you already have the data and the meeting becomes a 15-minute alignment instead of a 60-minute archaeology dig.

*Standup - [Day, Date]*
Yesterday:
- [What you did]
Today:
- [What you're doing]
Blockers:
- [If any]
🔁 Friction this week (1 line, optional):
- [Anything that wasted time, anything that worked well]

Filled-in example: Tuesday

*Standup - Tue, May 19*
Yesterday:
- Stripe webhook retry shipped
Today:
- Inngest wire-up
Blockers: none
🔁 Friction: PR review SLA still feels too slow; mine sat for 19 hours

Filled-in example: Wednesday

*Standup - Wed, May 20*
Yesterday:
- Inngest staging dual-write
Today:
- Failed-payment email pairing with Jin
Blockers: prod API key
🔁 Friction: pairing with Jin on Loom worked great, recording for the team

Filled-in example: Thursday

*Standup - Thu, May 21*
Yesterday:
- Failed-payment email merged
Today:
- Inngest 10% rollout
Blockers: none
🔁 Friction: staging environment was flaky for 2 hours this morning

By Friday, the team has five lines of friction signal collected without anyone scheduling a thing. The retro is a 15-minute call to vote on which two to fix next sprint. We pair this template with Loom for engineering communication so the Wednesday pairing note can include a 90-second video walkthrough.

Template 5: Weekly summary (Friday-only)

This sits on top of any of the daily templates above. Every Friday, each engineer posts a summary thread (not in the standup channel; in a #weekly-summary or #ship-log channel) for leadership and cross-team visibility.

*Week of [Mon date] - [Engineer name]*
Shipped:
- [Thing], [link to PR or Linear issue]
- [Thing], [link]
In flight (lands next week):
- [Thing], [current state]
Learned / decided:
- [Anything worth capturing]
Asks for next week:
- [Specific help, or "none"]

Filled-in example: Friday

*Week of May 19 - Alex*
Shipped:
- Stripe webhook retry: [PR #1247]
- Inngest billing dual-write: [PR #1251], [PR #1254]
- Failed-payment email: [PR #1258]
- Inngest 10% prod rollout (still running, no errors)
In flight (lands next week):
- Inngest 100% rollout, target Wednesday
- Customer portal cancel flow, scoping doc in Notion
Learned / decided:
- Inngest dual-write pattern works well for stateful migrations; documenting in our migrations playbook
Asks for next week:
- Product call on whether cancel flow needs a retention offer step

A non-engineer can read this in 30 seconds and know exactly what shipped and what is coming. The CEO does not need to ping the engineer to ask "what's the status of billing". The same post answers it.

What to do this week

Pick one template. Post it in your engineering channel today as a pinned message labeled "starting Monday: this is our standup format". Set a calendar reminder for two weeks out to evaluate. Do not change the format inside that window.

If your team is too small to support a standup ritual at all (one or two engineers), skip the format entirely and just push everyone toward a written daily commit log. The point is artifacts, not theater.

If you are scaling and need engineers who can already operate inside an async-first team, Cadence shortlists engineers in 2 minutes who have already passed a written-communication vet and an AI-native tooling check. Every engineer on Cadence is AI-native by default (Cursor, Claude Code, Copilot fluency vetted on a voice interview before they unlock bookings), which materially reduces the unblocking surface area. Median time to first commit across our 12,800-engineer pool is 27 hours.

If your remote standups are the thing slowing you down, try a 48-hour Cadence trial. Book a mid ($1,000/week) or senior ($1,500/week) engineer, run one of these templates with them on day one, and see how a candidate who already writes async-first changes the room. No notice period, replace any week.

FAQ

How long should an async standup post be?

Three to six lines, posted in under five minutes. If it takes longer than five minutes to write, the engineer is treating it like a status report for management instead of a coordination signal for peers. Keep it short and let the thread carry the depth.

Should we still do a live weekly meeting if we run async standups?

Yes, but not as a status meeting. A 30-minute weekly call works well for decisions that need real-time discussion: architectural calls, hiring decisions, prioritization arguments. Status is async. Decisions are sync. Do not confuse the two.

What if an engineer skips standup?

One miss is normal (sick day, deep work morning, time zone). Three misses in two weeks is a signal. The fix is not punitive; it is a 1:1 conversation about what the standup is for and whether the format is wrong for them. For a deeper framework on how to evaluate engineers asynchronously, see our post on writing performance reviews for remote engineers.

Do AI tools change what goes in a standup?

Yes, in two ways. First, "yesterday" lines compress because an engineer using Cursor or Claude Code ships more in a day, so the bullet list gets longer per person. Second, the blocker line shifts: less "I don't know how to do this" (Claude unblocks that) and more "I need a decision from a human" (which is what a standup is actually good at routing).

How do we onboard a new engineer to our standup format?

Pin the template in the channel, show them a week of past posts, and have them post on day one (even if day one is just "joined, reading the codebase, paired with X on setup"). For the full onboarding playbook, read our guide on onboarding remote developers quickly.

Which template should a brand new team start with?

Template 1, the basic Y/T/B. Run it for two weeks unchanged. Then look at where it is failing (too much noise? not enough blocker resolution? leadership asking for weekly summaries?) and graduate to template 2, 3, 4, or 5 based on that specific failure. Do not start with template 4 or 5; you are skipping the learning that makes those formats useful.