A daily stand-up is a short, structured check-in where each team member answers three questions: what did I finish, what am I working on today, and what is blocking me. Done well it takes under ten minutes, keeps the team aligned without a meeting, and surfaces blockers before they compound into missed deadlines.
Done poorly — in a 45-minute Zoom call that could have been a message, or in a tool nobody checks — it is a ritual that costs the team time without returning any of it.
Slack is where most teams already communicate. Running the standup there, asynchronously, removes the scheduling overhead, respects time zones, and creates a searchable written record of what the team was working on — which is useful for project reviews, retrospectives, and performance conversations. This guide covers how to set up a Slack standup that works, the questions to ask, common failure modes, and how Time Bot connects standup data to actual time tracking.
What is a daily stand-up?
A daily stand-up (also called a daily scrum, daily check-in, or daily sync) is a short recurring team ritual in which each member briefly shares what they completed, what they are working on, and any blockers in their way. The name comes from agile software development, where teams stood up to keep the meeting short — the discomfort of standing was a physical reminder to be brief.
The purpose is coordination, not status reporting. A standup is not a meeting for the manager to collect updates. It is a mechanism for the team to stay aligned, to surface dependencies before they become problems, and to create a daily moment of shared context without requiring everyone to be in the same place at the same time.
In Slack, the standup becomes asynchronous — each person answers the questions in their own time, the responses are posted to a shared channel, and anyone can read them at any point in their working day. This works particularly well for distributed teams, teams across time zones, and teams where synchronous meetings have a high cost.
Why async standups in Slack outperform synchronous meetings
The synchronous standup has a fundamental problem: it requires everyone to be available at the same time. For a co-located team with overlapping hours this is manageable. For a team with one person in London, two in New York, and one in Singapore it is impossible without someone losing sleep or starting their day at an unreasonable hour.
Even for co-located teams, the synchronous standup has costs that go unexamined. It requires a fixed 15 minutes blocked on every calendar. It requires everyone to be mentally prepared to speak at the same moment. It is synchronous by nature, which means the information flows in one direction at a time — each person speaks while everyone else listens. And if someone is five minutes late or has to drop early, the whole structure is disrupted.
The async Slack standup solves all of these. Each person answers the questions when they sit down to work — before their first task, not at a scheduled interruption. The answers are written, which means they are precise and searchable. Everyone reads them in their own time and absorbs all the information in parallel rather than sequentially. And there is no scheduling overhead, no video fatigue, and no “you’re on mute” moment.
What async standups do not automatically solve is the problem of accountability. In a synchronous meeting, the social pressure of speaking in front of colleagues produces participation. In an async channel, there is no equivalent pressure. This is why the setup and norms matter — and why a standup bot that sends prompts and tracks participation is more reliable than a channel and a hope.
The three standup questions — and better alternatives
The classic three standup questions come from Scrum:
- What did I complete since the last standup?
- What will I work on until the next standup?
- What is blocking me?
These work. They are also not the only options, and for some teams they are not the best options. Here are variations and additions that produce better standup quality.
Variations on the classic format
For outcome-focused teams (better than task-focused):
- What outcome did I move forward since yesterday?
- What outcome am I trying to move forward today?
- What is preventing progress?
The distinction matters. “Wrote code for the login feature” is a task. “Moved the login feature to review-ready” is an outcome. The second is more useful information for the team.
For teams where blockers are underreported:
- What is the one thing that would help you most move faster right now?
This is a different framing for the blocker question that is easier to answer honestly. “I am blocked” implies failure; “here is what would help” invites the team to contribute.
For remote teams building connection:
- One non-work thing: [anything]
Optional, at the end. Creates the casual context that remote teams miss and that in-person teams get informally.
For teams tracking time on specific projects:
- What project did I log most of my time to yesterday?
- What project will I focus on today?
- Any changes to the plan that affect estimates?
This version connects the standup directly to time tracking data, which is the combination covered later in this article.
How to set up a daily standup in Slack
Option 1 — Manual channel with agreed norms
Create a dedicated channel: #standup, #daily-updates, or #team-status. Pin a message at the top with the three questions and the expectation (e.g. post before 10am your local time). Team members copy the format, answer the questions, and post.
This works for small, disciplined teams. It fails when participation is inconsistent — which it will be, eventually, without a prompt — and it produces no structure that makes the data searchable or summarisable over time.
Option 2 — Slack Workflow Builder (native, free)
Slack’s built-in Workflow Builder can send a scheduled message to a channel with the standup questions at a configured time. It is free, requires no third-party app, and works in any timezone.
The limitation: Workflow Builder sends the questions as a channel message, not as individual prompts. It cannot collect responses in a structured format, track participation, or produce summaries. For teams that just need a daily prompt, it is sufficient. For teams that want any analytics or structure, it is not.
Option 3 — A standup bot
Standup bots send individual prompts to each team member at their configured time, collect responses in a structured format, post a compiled summary to the designated channel, track participation over time, and often produce reports on blocker frequency, participation rates, and response patterns.
For teams where time tracking is already happening in Slack — using Time Bot — the standup becomes part of a connected picture of the working day: what someone said they would do, what they actually tracked time against, and how those two data sets compare.
How Time Bot runs standups in Slack
Time Bot includes a built-in standup feature that integrates with its time tracking. The standup is configured in the Time Bot settings and fires automatically at each team member’s local start time.
Default standup questions:
- What have you finished since yesterday?
- What will you do today?
- Any impediments in your way?
All three are fully customisable. Add questions, remove them, change the wording. The standup fires when each person starts their day relative to their timezone — a team member in Berlin gets the prompt at their 9am, a team member in Toronto gets it at theirs. No one gets woken up or interrupted.
Responses are broadcast to a designated Slack channel. The whole team sees the compiled standup update for the day in one place.
The connection to time tracking
Where Time Bot differs from a dedicated standup bot is the connection between what someone says they will do and what they actually track. A team member who writes “finishing the client API integration today” in their standup and then logs /t client API integration when they start, /t code review — frontend when they switch, and /t break when they step away is creating a detailed, timestamped record of their day that sits alongside their standup statement.
Managers who open the daily report email can see both: the standup’s intention and the time log’s reality. If someone consistently says they are working on one thing and logs time to another, that is a project priority signal. If the standup says “blocked on design handover” and the time log shows the same person logging six hours to a different project, that context is useful for understanding how the team is actually spending its capacity.
Setup:
Go to Settings in the Time Bot admin panel. Under Standup, toggle it on, configure your questions, and set the channel where responses should post. The timing is automatic — Time Bot uses each user’s configured timezone from their profile.
Standup questions for different team types
Engineering teams
- What did I ship, review, or close since yesterday?
- What am I working on today — ticket number if applicable?
- Anything blocked, waiting on someone else, or at risk?
The specificity of “ticket number if applicable” cuts ambiguity without making it mandatory. Engineers often know exactly what the relevant identifier is; the invitation to include it makes standups more useful for cross-referencing with the project tracker.
Client services and agencies
- What client work did I complete or progress yesterday?
- What am I focused on today and for which client?
- Any scope, timeline, or client communication issues worth flagging?
The client reference is important in agency standups. Time tracked without project context is useful for internal reporting but not for client billing. Standups that include client names create the habit of thinking in client-attributed time.
Remote and distributed teams
- What did I accomplish since my last working day?
- What is my focus today?
- Anything I need from someone else?
- One thing (optional): [anything, work or not]
“Since my last working day” rather than “yesterday” accommodates different schedules and time zones without requiring explanation. The optional fourth question builds the human context that distributed teams lose without hallway conversation.
Product and design teams
- What did I move forward or complete?
- What am I designing, researching, or reviewing today?
- Any dependencies on engineering, data, or stakeholder input that are at risk?
Design standups benefit from explicit dependency flagging — design work is frequently blocked on decisions or inputs from other functions, and the standup is the right mechanism to surface that before it silently holds up a sprint.
Common standup mistakes and how to fix them
The standup becomes a status report for management
When team members write standups for the manager rather than for each other, the format becomes performative. Updates are written to look good rather than to be useful. The fix: the manager should not be the only person responding to or acknowledging standup updates. Encourage peer responses — a simple emoji reaction or a “good luck with that, let me know if you need anything” — so the channel feels like team communication rather than reporting.
Nobody reads the standups
If updates go unread, people stop bothering to write them well. The fix: make the standup channel something people actually check. Use it for follow-up — “saw you mentioned you were blocked on X, I can help with that” — and reference it in meetings. If standup information is never acted on, it signals that nobody is paying attention.
The blocker question is always “none”
Real teams have real blockers. If the standup consistently shows “none” on blockers, either the team has unusually good working conditions or — more likely — the format is not creating psychological safety to admit difficulty. The fix: reframe the question (“what would help you move faster?”) and model honesty from the team lead by naming their own blockers publicly.
Participation is inconsistent
Some team members post every day; others forget for days at a time. The fix: a standup bot with individual prompts and participation tracking is significantly more reliable than a channel norm. When people get a direct message prompt at their work start time, participation rates are consistently higher than when they are expected to remember independently.
The standup and the actual work are disconnected
A team member writes “working on the user onboarding flow” in their standup and then logs time to three other projects for the rest of the day. This is not lying — priorities shift — but the disconnect is invisible without time tracking. The fix: connect the standup to time tracking, even loosely. Seeing the gap between intention and reality, over time, is one of the most useful planning inputs a team can have.
Standup + time tracking — the combination that creates real visibility
A standup tells you what someone planned to do. Time tracking tells you what they actually did. Together they create a picture of the working day that neither produces alone.
The practical benefits:
Better estimation. When you can compare what a team member said they would work on with what they actually tracked, over weeks and months, the patterns in estimation error become visible. Teams that review standup-vs-actual data produce better sprint plans than teams that estimate from intuition alone.
Blocker resolution at the right level. A standup that says “blocked on API documentation” and a time log that shows the same person logging six hours to a different project on the same day tells you two things: the blocker is real, and the person found something else useful to do while waiting. That is useful context for a manager deciding whether to escalate the API documentation issue.
Capacity visibility for distributed teams. Managers of distributed teams rarely have accurate intuition about how their team’s time is being spent. The standup provides intention; the time log provides reality. Daily email reports from Time Bot give managers the time data without requiring them to ask — which is the kind of visibility that makes remote management genuinely work rather than requiring trust in the absence of information.
Recognition opportunities. A standup that mentions a difficult problem solved, combined with a time log that shows the significant hours invested in solving it, gives a manager the specific, named context for a genuine recognition moment: “I saw in your standup that you were dealing with the data migration issue, and looking at your time log it took you most of Tuesday and Wednesday. That deserved more than a note in passing — thank you.”
Add Time Bot to Slack — 7-day free trial →
FAQ
What is a daily stand-up? A daily stand-up is a short recurring check-in where each team member briefly shares what they completed since the last standup, what they are working on today, and any blockers preventing progress. It originated in agile software development and is used by remote, hybrid, and co-located teams to maintain alignment without requiring synchronous meetings. In Slack, standups are typically run asynchronously — each person answers the questions when they start work, responses are posted to a shared channel, and the whole team reads them in their own time.
What questions should a standup include? The classic standup questions are: what did I complete since the last standup, what will I work on today, and what is blocking me. These work well for most teams. Variations worth considering: replacing “what did I complete” with “what outcome did I move forward” (focuses on results rather than tasks), replacing “what is blocking me” with “what would help me move faster” (easier to answer honestly), and adding an optional non-work item for remote teams building connection.
How do you run a standup in Slack? You can run a Slack standup manually (create a dedicated channel, pin the questions, agree on a posting time), using Slack’s native Workflow Builder (sends a scheduled prompt for free), or using a standup bot that sends individual prompts, collects responses in a structured format, tracks participation, and posts compiled summaries. For teams already using Time Bot for time tracking, the built-in standup feature connects standup responses to actual time logs, creating a picture of what the team planned versus what they actually worked on.
What is the best time to run a standup? The best time for an async Slack standup is at each person’s local work start time — not a single fixed time that requires everyone to be available simultaneously. A standup bot that fires prompts relative to each user’s configured timezone solves this automatically. For synchronous standups, research consistently shows that morning standups (within the first hour of the workday) produce better participation and more accurate blocker flagging than midday or end-of-day formats.
How long should a standup be? A synchronous standup should be 15 minutes maximum — the constraint is deliberate and functional. An async Slack standup has no fixed duration, but individual responses should take under five minutes to write. The goal is a brief, focused update — not a detailed project status. If responses routinely run long, the question format may need simplifying or the team may need a reminder that standups are for coordination, not for comprehensive reporting.
What is the difference between a standup and a stand-up meeting? A stand-up meeting is a synchronous, typically in-person or video-call-based meeting where team members stand (or act as if they are standing) to keep the session brief. A standup — without the hyphen in most modern usage — often refers to the async equivalent: each person posts their update independently, and the compiled responses serve the same coordination function without requiring a scheduled block of time. In practice the terms are used interchangeably regardless of format.
