LithoBlocksSlack messages have limits at several levels: blocks, text objects, interactive elements and API throughput. Distinguish an API limit from a readability recommendation, and distinguish Slack’s rules from the limits enforced by your template tool.
Start with the surface
Slack permits up to 50 blocks in a message and 100 in a modal view. Repeated sections, dividers and action rows all use that allowance. A long array can consume it much faster than a small sample suggests. See Slack’s block overview.
Before rendering an unbounded list, decide how many items the reader needs. Summarize the rest and link to a full report. A threaded follow-up is another message, with its own delivery behavior and cost.
Common text limits
| Field | Limit or guidance |
|---|---|
| Section text object | 3,000 characters |
| Header text | 150 characters |
| Button label | 75 characters |
| Button value | 2,000 characters |
| Action ID | 255 characters |
| Top-level message text | Aim for 4,000 characters; Slack documents truncation beyond 40,000 |
The top-level text field is not subject to a hard 4,000-character ceiling. Its job alongside blocks is to provide a useful fallback, including notification and accessibility content. Include the information someone needs without depending on a visual layout. Slack can also attempt to construct accessible text from supported blocks when top-level text is omitted; do not assume that every omission produces an empty notification. Slack’s message documentation.
Actions: capacity is not a design target
An actions block supports up to 25 elements, not five. A message with one primary action and a few secondary choices is usually easier to read. That is a design recommendation, not a different API limit. An overflow menu is for secondary actions, not for hiding paragraphs of content. Actions block reference.
Rate limits are a separate problem
chat.postMessage has special rate limits. Slack generally permits one message per second to a particular channel, with additional workspace-wide limits and burst behavior. It is not a Tier 3 method limited to one call per second per workspace.
Honor rate-limit responses and their retry timing. For a LithoBlocks operation with an uncertain outcome, inspect its result before starting a new operation. Where supported, preserve the same idempotency key and request body for a retry.
What LithoBlocks handles
The builder makes block usage visible, and compilation handles supported text truncation and directive overflow. These features help with common limits; they do not guarantee that every payload can be delivered. Invalid structure, oversized metadata, missing context, destination permissions and Slack errors can still stop a send.
Use free authoring validation for diagnostics, then inspect a rendered preview when needed. A standalone compile uses 1 credit; sending that result through a separate template-send operation is another metered operation. Read returned warnings instead of silently discarding them.
A useful preflight
- Preview an empty dataset, a typical dataset and a large one.
- Test long text and missing values.
- Check the fallback content and primary action on desktop and mobile.
- Decide what should be summarized or linked out.
- Inspect validation diagnostics and any truncation warnings.
The LithoBlocks limits guide and block schema describe application constraints. For tables, use the current table guide. For noisy streams of events, a digest queue can reduce notification volume before rendering begins.