Slack error msg_too_long: Message text is too long

The text you sent exceeds what the method will accept, and Slack rejected the whole message — nothing was truncated for you, nothing was delivered. The chat.update reference is the most explicit about the boundary: "Message text is too long. The text field cannot exceed 4,000 characters." On chat.postMessage, the documentation's guidance is layered: "For best results, limit the number of characters in the text field to 4,000 characters," and separately, "Slack will truncate messages containing more than 40,000 characters." In practice: treat 4,000 as your working budget, 40,000 as the hard wall, and msg_too_long as the sign your content blew past what the endpoint tolerates.

The usual culprits are machine-generated payloads: stack traces, JSON dumps, CI logs, LLM output, or a loop that concatenates a day's worth of items into one send. Message length is counted on the final string after your templating runs, so a template that looks short can inflate enormously with real data. Note that blocks have their own separate budgets — 50 blocks per message and 3,000 characters per section text — with their own errors (invalid_blocks and msg_blocks_too_long), so fixing text does not exempt your Block Kit payload, and vice versa.

Design the fix around intent rather than blind chunking. If the content is a log or document, the right Slack primitive is a file upload (via files.getUploadURLExternal/files.completeUploadExternal) with a short message pointing at it — files render with preview and don't fight message limits. If the content is genuinely conversational, truncate with an explicit marker and a link to the full version, or split on paragraph boundaries into a thread: first message top-level, the rest as replies with thread_ts, which keeps channels readable. Blind 4,000-character splits mid-word or mid-code-fence produce mangled formatting and, with markup, can break entity boundaries.

The error is deterministic — the same payload will fail every time — so automatic retries are pure waste. Both official SDKs surface it as an ordinary platform error (ErrorCode.PlatformError in @slack/web-api, SlackApiError in slack_sdk) and neither retries it. See the full length table in Slack message limits.

{"ok": false, "error": "msg_too_long"}

Put a length gate in the one code path that talks to Slack: everything above the cap is summarized or attached, never sent raw. Design templates with worst-case data in mind, and unit-test them with maximal inputs. For alerting bots, prefer 'summary in the message, detail in the file/link' as the default shape — it survives every limit in the message-content table.