Slack message character limit: 40000 characters, threads, and main channel etiquette
Slack messages are easy to write and easy to overgrow. A launch note, incident update, design critique, support summary, or pasted log can become a wall of text before anyone notices. Slack gives you a large message limit, but the team cost appears in the channel: people miss the action, threads fork, and mobile readers give up. The useful question is not only whether Slack accepts the message. It is where the message belongs.
The limit, exactly
Slack recommends keeping messages under 4,000 characters for readability and truncates messages above 40,000 characters. Count spaces, punctuation, line breaks, emoji shortcodes, mentions, channel references, URLs, markdown-style formatting, code fences, pasted logs, and quoted text. Attachments and Block Kit payloads have their own field limits, so an app-generated message can fail even when the visible text looks short. If you paste a stack trace, every repeated line counts. If you mention a user group, that mention counts in the message and also raises the notification stakes. The platform can carry long text, but Slack's own developer docs encourage shorter messages and alternative upload methods for very long content. Workflow templates should be tested with worst-case values, not tidy examples.
What displays vs what is stored
Slack stores messages in channels, DMs, threads, search, notifications, and mobile push previews. Those surfaces do not display the same amount of text. A long message may be truncated, collapsed, or skimmed only through its first lines. In channels, the first sentence becomes the practical subject line. In threads, context stays attached but visibility drops for people who are not following the thread. Code blocks and quoted text can make a message much taller than its character count suggests. For durable decisions, use a short Slack summary and link to the issue, doc, incident report, or pull request where the full record belongs. Search later works best when the message names the project, system, and decision clearly.
Real-world tips
- Put the ask first. `Please review the API wording by 3 PM` is clearer than three paragraphs of background followed by a hidden request. Slack is a work queue as much as a chat tool.
- Use threads for context, not for urgent visibility. Start with a concise channel message that names the topic and action, then place logs, notes, and back-and-forth in the thread.
- Move long logs to files or linked tools. A few lines of error output are useful. Thousands of characters of repeated trace output make search noisier and bury human explanation.
- Use bullets for status updates. `Impact`, `Current status`, `Next update`, and `Owner` are faster to scan than a narrative incident paragraph. This matters on mobile during live work.
- Be deliberate with mentions. A long message that begins with `@channel` should justify that interruption immediately. If only two people need to act, mention those people near the task.
- For app messages, check Block Kit limits separately. Section text, context fields, button labels, and plain message fallback text do not all share one simple 40,000-character bucket.
- End with the next checkpoint. Long Slack updates often fail because readers cannot tell whether the sender needs feedback, approval, silence, or action. A final line like `Next update at 14:30 UTC` or `Please review the risk section only` turns context into workflow.
Common mistakes
- Posting a document-length update in a busy channel instead of linking to the source of truth.
- Starting with background when the reader needs the decision, blocker, or deadline first.
- Using a thread for an urgent announcement that everyone must see.
- Pasting secrets, tokens, or private customer data while trying to share enough debugging context.
- Assuming app-generated Slack text follows the same limits as a manually typed message.
- Letting a thread become the only record of a decision. Slack is searchable, but it is not a substitute for updating the issue, runbook, or project document after the discussion settles.
Use the counter
Use the Slack counter before sending announcements, incident updates, support summaries, or app-generated fallback text. If the draft is above 4,000 characters, ask whether it should become a doc or thread. If it approaches 40,000 characters, Slack is the wrong storage place for the full content. For templates used by bots or workflows, count the worst-case version with long user names, channel names, URLs, and error strings included.
Related platforms
Slack belongs with Discord and Telegram for chat-style limits, but its workplace expectations make threads and source-of-truth links more important. Compare those guides before turning one update into three channel posts. Reddit is a useful contrast when a question deserves a public, searchable answer instead of another internal chat thread.
Source notes
Platform limits and display behavior can vary by surface. These references are useful starting points for the current published rules:
For fields where the platform does not publish a stable public number, this guide uses the conservative limit planned for the Phrasit counter and calls out practical display behavior separately. That distinction matters: a field can accept more text than most viewers will ever see, and a third-party scheduler can reject copy that the native composer accepts. Recheck the live composer before high-stakes campaigns, policy posts, paid placements, or messages that include required legal wording.