DOCS-1738 - Document 256KB log message size support - #6881
Conversation
Update max log message size references from 64KB to 256KB across search, collection, and source docs; add a Known limitations section and LogCompare/LogReduce truncation notes; clarify the FER 64KB cap; and add a service release note. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Update the Log Search messages-table limitation to the GA behavior (table shows up to 64KB after expansion; full message via Log Message Inspector), and drop the unverified large-log source examples from the release note. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Holding off on approval — the PR description lists three open items still unconfirmed:
Could you confirm these and check the boxes before this goes up for merge? The doc mechanics (links, cross-references, consistency of the 64KB→256KB updates across all affected files) all check out — just want the factual claims nailed down first. |
Adds known-limitation notes for Slack's message truncation and Jira Cloud's 32,767-character issue description limit, called out directly on each webhook connection page and cross-linked from the central 256KB known limitations list, since larger messages make both limits more likely to be hit.
Adds Slack's 40,000-character hard limit, splits the search-large- messages known limitations into Sumo Logic platform vs. downstream webhook connection limitations for clarity, previews both in the intro, and tightens the release note with the same distinction.
| We're excited to announce that Sumo Logic now supports a maximum log message size of **256KB**, up from 64KB, so large single-line logs are ingested without being split as often. | ||
|
|
||
| **Sumo Logic platform limitations:** | ||
| * LogCompare, LogReduce, Cloud SIEM parsing, and Field Extraction Rules still process messages at 64KB. |
There was a problem hiding this comment.
Is this Field Extraction Rule limitation accurate? This makes it sound like FER will only work if the log is <64kb. I thought the limit was in the volume extracted?
There was a problem hiding this comment.
FER can work with 256KB logs, it just cannot extract cumulative 64kb values for all fields
There was a problem hiding this comment.
Good catch — the bullet was misleading. Per lei-sumo's clarification (FER works with 256KB logs, it's the cumulative extracted-field size that's capped at 64KB, not the message itself), removed this summarized bullet entirely rather than try to compress it further. See 4a6dd93cb. — via Claude Code
| These features process large messages differently within Sumo Logic itself: | ||
|
|
||
| - **LogCompare and LogReduce**. These operators truncate raw 256KB messages to 64KB before matching and grouping the logs into signatures, so content beyond 64KB is not considered. This can also affect response time when you run them against large messages. Learn more in [LogReduce](/docs/search/behavior-insights/logreduce/) and [LogCompare](/docs/search/behavior-insights/logcompare/). | ||
| - **Log Search messages table**. The messages table displays up to 64KB of a message, even after you expand it. To view a complete message larger than 64KB, use the [Log Message Inspector](/docs/search/get-started-with-search/search-page/log-message-inspector). |
There was a problem hiding this comment.
After this feature is released, the message table will display messages up to approximately 25 KB.
@JV0812, could you please update this?
Also, please add a note that messages larger than 25 KB containing JSON values as strings will not be rendered as JSON fields by default in the table. To view them as structured JSON, users will need to open the message in the Message Explorer.
YOu can read more on this thread https://sumologic.slack.com/archives/C09NL5MKJUS/p1784608962471479?thread_ts=1779369449.778359&cid=C09NL5MKJUS
There was a problem hiding this comment.
Updated — the messages table limit is now documented as 25,000 characters (GA behavior), and added a note that JSON values in messages beyond that size aren't rendered as JSON fields by default in the table; the Log Message Inspector shows the full message and structured JSON. See 4a6dd93cb. — via Claude Code
| **Downstream webhook connection limitations:** | ||
| * Slack (40,000 characters) and Jira Cloud (32,767 characters) enforce their own limits, which larger messages are more likely to reach. | ||
|
|
||
| [Learn more](/docs/search/get-started-with-search/search-basics/search-large-messages/). |
There was a problem hiding this comment.
from a discussion with @kevin-sumo, we suggest to skip the above limitation paragraphs, but just mention to find limitations using this link.
There was a problem hiding this comment.
Done — removed both summarized limitation sections and replaced with a link to the Known limitations section of the main doc. See 4a6dd93cb. — via Claude Code
| ## Known limitations | ||
| The Jira Cloud issue description field has a hard limit of 32,767 characters, enforced at the database level. If a payload variable such as `{{ResultsJson}}` pushes the **Issue Description** past this limit, Jira Cloud returns a `400 Bad Request` error and the issue is not created. To avoid this, reference individual result fields (for example, `{{ResultsJson.fieldname}}`) instead of the full `{{ResultsJson}}` object, or otherwise keep the payload within the limit. |
There was a problem hiding this comment.
@JV0812 We did a fix for this, the behavior is that Issue description will be truncated at 32KB and issue will still be created. Could you update this accordingly?
There was a problem hiding this comment.
It is also truncated with "…", similar as the slack webhook.
There was a problem hiding this comment.
Updated — Known limitations now says the description is truncated with "..." and the issue is still created, matching the Slack webhook behavior, instead of a 400 Bad Request failure. See 4a6dd93cb. — via Claude Code
| Alert notifications sent to these tools can also be affected by character limits that are fixed by the tool itself, independent of Sumo Logic's message size. Larger messages make these limits more likely to be reached: | ||
|
|
||
| - **Slack webhook connections**. Slack has a hard limit of 40,000 characters per message. Content beyond this limit, such as a large `{{ResultsJson}}` value, is truncated with "…" in the notification. Learn more in [Known limitations](/docs/alerts/webhook-connections/slack/#known-limitations). | ||
| - **Jira Cloud webhook connections**. The Jira Cloud issue description field has a hard limit of 32,767 characters. A payload variable such as `{{ResultsJson}}` that exceeds this limit returns a `400 Bad Request` error. Learn more in [Known limitations](/docs/alerts/webhook-connections/jira-cloud/#known-limitations). |
There was a problem hiding this comment.
Need to update this as well: issue can be created with a truncated payload.
There was a problem hiding this comment.
Updated — this bullet now says the Jira Cloud payload is truncated with "..." and the issue is still created, instead of returning a 400 Bad Request. See 4a6dd93cb. — via Claude Code
lei-sumo
left a comment
lei-sumo
left a comment
There was a problem hiding this comment.
during GNG meeting, we made another pass and left several comments.
…elease note - Correct the Log Search messages table limit from 64KB to the GA value of 25,000 characters, and note that JSON values in larger messages aren't rendered as JSON fields by default (per ssharma-sumo). - Correct Jira Cloud webhook behavior: oversized descriptions are truncated with "..." and the issue is still created, not a 400 Bad Request failure (per lei-sumo). - Drop the release note's summarized limitations bullets, which mischaracterized the Field Extraction Rule limit as a message-size cap rather than a cumulative-field-size cap (per kevin-sumo/lei-sumo), and link to the doc's Known limitations section instead.
| These features process large messages differently within Sumo Logic itself: | ||
|
|
||
| - **LogCompare and LogReduce**. These operators truncate raw 256KB messages to 64KB before matching and grouping the logs into signatures, so content beyond 64KB is not considered. This can also affect response time when you run them against large messages. Learn more in [LogReduce](/docs/search/behavior-insights/logreduce/) and [LogCompare](/docs/search/behavior-insights/logcompare/). | ||
| - **Log Search messages table**. The messages table displays up to 25,000 characters of a message, even after you expand it. If a message larger than 25,000 characters contains JSON values as strings, those values are not rendered as JSON fields by default in the table. To view a complete message, or to view large JSON values as structured JSON, use the [Log Message Inspector](/docs/search/get-started-with-search/search-page/log-message-inspector). |
There was a problem hiding this comment.
@AyanGhatak @ssharma-sumo can you review and confirm the accuracy of this updated paragraph?
5 participants
Purpose of this pull request
This pull request documents the increase of the maximum log message size from 64KB to 256KB, calls out the known limitations, and adds a service release note.
Changes:
_sizetruncation from 65536 to 262144) insearch-large-messages.md,collect-multiline-logs.md,cloud-syslog-source/index.md, andqualys-vmdr-source.md.search-large-messages.md(LogCompare/LogReduce, UI 25-messages-per-page, Cloud SIEM, FER).logcompare.mdanddetect-patterns-with-logreduce.md.fer-limitations.mdthat the 64KB cumulative field cap applies regardless of message size.blog-service/2026-07-09-search.md.Open items to confirm before marking ready
Select the type of change
Ticket (if applicable)
https://sumologic.atlassian.net/browse/DOCS-1738 (epic: SUMO-288529)