AstrolinksYour team is spread across Manila, Lisbon and Chicago. There's no hour of the day when everyone is awake and working. A live daily standup means someone joins at midnight, and the meeting still runs long.
Async check-ins solve that. Each person writes a short update when their day ends, and the people who need it read it when their day starts. Nobody waits on a call. This guide covers how to run async check-ins for remote teams: the format, the timing, where to post, how managers should respond, and the mistakes that turn a useful habit into a chore.
What an async check-in is
An async check-in (often called an async standup) is a short written update each person posts on a set rhythm, usually daily. It answers a few fixed questions, so everyone can scan it fast.
It's async because the writer and the reader don't need to be online at the same time. You write at the end of your shift. Your manager reads it with coffee the next morning, in their own time zone.
It replaces most of what a live standup does: sharing progress, raising blockers and agreeing on what's next. It doesn't replace real conversations. When something needs a discussion, have one.
Morning or end of day?
There are two common timings.
Morning check-ins state the plan: "Today I'll finish the billing page." They're good for coordination, but they're guesses. Plans change by lunch.
End-of-day check-ins report what happened: "Finished the billing page, the tests are in review." They're more accurate, they need no memory from the day before, and they suit teams across time zones, because one person's end of day is often the next person's morning.
For most remote teams, end of day is the better default. Our guide on daily standups vs. EOD reports goes deeper on the trade-off.
A 3-question format
Keep it to three questions. Every extra field makes the update slower to write and harder to read.
- What did you get done? Outcomes, not activity. "Shipped the export fix" beats "worked on bugs".
- What's in progress or blocked? Name the blocker and who can clear it.
- What's next? One to three items for the next working day.
That's enough for almost any team. A written check-in that takes three minutes gets written every day. One that takes fifteen gets skipped by Thursday.
If you want help writing good answers, how to write an end-of-day report covers the method in detail.
Time zones: post at the end of each shift
The rule is simple: each person posts at the end of their own shift. Managers read in their own morning.
That gives a natural relay:
- A VA in Manila finishes at 6 AM local time and posts.
- A manager in New York reads it at 9 AM their time, replies, and clears any blockers.
- The VA starts their next shift with answers already waiting.
Don't ask everyone to post at the same clock time. 5 PM Chicago is 6 AM Manila. Someone will be writing in the middle of their night.
If your team works with clients in other time zones, write times in the reader's zone when they matter: "Sent at 2:10 PM your time."
Where to post
Pick one place and stick to it. The worst setup is updates scattered across DMs, email and three channels.
Good options:
- One shared channel, like #check-ins in Slack or Teams. Easy to scan, easy to reply in a thread.
- One inbox for reports, if updates contain client details that shouldn't sit in a busy channel.
- A thread per day, if the team is small and you want everything in one view.
Whatever you choose, keep the format the same every day so readers know where to look.
How managers should respond
The way managers respond decides whether async check-ins work. People keep writing honest updates when the replies are useful. They stop when the replies feel like an audit.
Do:
- React or reply to every check-in, even with a thumbs-up. Silence makes people wonder whether anyone reads them.
- Unblock first. If someone is waiting on access, a decision or a review, that's your top job for the morning.
- Ask one clear question when you need detail, in a thread, not in a call.
- Notice good work by name. It doesn't need a speech.
Don't:
- Interrogate. "Why did this take so long?" under every update teaches people to write less.
- Compare people's updates in public.
- Turn a short blocker into a meeting unless it really needs one.
For more on this, see remote team updates without micromanaging.
A weekly rhythm
Daily check-ins cover the details. Once a week, zoom out.
- Friday (or the last workday): each person adds a short weekly recap: the main results, what slipped, and the focus for next week.
- Monday: the manager posts the team's priorities for the week in the same place.
- Once a month: ask the team if the format still works. Remove a field if nobody uses it.
The weekly recap is often more useful to leaders and clients than five daily updates. Weekly client recap templates has formats you can adapt for a team.
Common mistakes
Too many fields
Mood scores, energy levels, links to every ticket, a "learned today" box. Each feels harmless. Together they make a form nobody wants to fill. Start with three questions. Add a field only when the team asks for it.
Asking for hours as proof
If the check-in asks "How many hours did you work?" just to prove people were busy, it stops being a check-in. It becomes monitoring with extra steps. Ask for hours only where they're needed for billing or a client's cap, and keep that separate from the progress update.
Using it to monitor
A check-in is for coordination: who needs what, and what's moving. If managers use it to judge whether people looked busy enough, people will write updates that look busy. You'll lose the honest blockers, which were the point.
No reply, ever
Updates that disappear into a channel with no reaction get shorter every week, then stop.
Templates you can copy
VA agency
[Name], [Client], [Date]
Done: Cleared inbox to zero, booked 3 calls for Thursday, sent the October invoice reminders.
Blocked: Need the new CRM login from the client.
Next: Draft next week's newsletter, follow up on 2 unpaid invoices.
One check-in per client keeps each client's work separate, and the agency lead can forward it as is.
Dev team
[Name], [Date]
Done: Merged the export fix. Reviewed 2 pull requests.
In progress / blocked: Payment webhook tests failing on staging. Need someone with access to the sandbox keys.
Next: Finish webhook retries, start the settings page.
Support team
[Name], [Shift], [Date]
Done: Closed 42 tickets, 3 escalated to billing.
Blocked / patterns: Several customers asking about the new login screen. Worth a help article.
Next: Follow up on the 3 billing escalations.
The "patterns" line is the part leaders value most in support check-ins. It turns individual tickets into something the product team can act on.
One inbox, written by the person, not a monitor
Most of the effort in a daily check-in is remembering the day. Astrolinks is a Mac app that keeps a private log on each person's own computer and drafts their end-of-day report at clock-out. They read it, edit it and send it.
On the Team plan, those reports go to one company Team inbox. The company sees only the reports a person chooses to send, never their activity, apps or websites. Managers can also send tasks and goals back, with a note and a due date. It's built on the same idea as this guide: clarity, not surveillance.
See the Team inbox, or read about Astrolinks for remote teams.